对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全

看样子社会的毒打还不够多，就效率上来说全用 POST 减少了大量开发成本和沟通成本，更快交付项目。他的理由说错了罢了

我们是绝不允许使用这种垃圾技术

见过用 POST ，但所有参数拼接在 URL 上的吗？

@jfcai 见过用 Get ，所有参数都放在 body 里面吗

1. 公司或者部门有规范，按照公司规范来，没有的话，公司有点问题，没做好
2. 老项目，按已有的 API 规范来
3. 新项目，看项目能不能达成一致使用 RESTful 风格的 API 设计，不能达成一致，使用 RPC 风格的 API 也不是什么问题

当然，面对说 POST 更安全，这种极其不靠谱的后端，可能及时跑路更好

我之前的组，强制规定，所有请求全部用 POST

https 是传输数据全加密的，除了请求的目标 IP ，中间设备是抓不到任何内容的，path 部分 body 体都一样，除非请求发起端被黑了，信任了中间人的证书，然后被中间人劫持。
（题外话，所以不要在公司的加域电脑或者需要安装上网控制的内网上干私人的事，对于 IT 和老板你 https 了也是光屁股的）

这个后端找借口都不会 ， 我教他俩百分百对的。
"Restful 对于某些业务很难抽象，比如网上各种对注册登录的实现，要么破坏规则与其他 restful 不统一，要么强行把简单的逻辑抽象成了复杂还别扭的规则。"

"公司运维有统一请求分析控流组件，每个项目都是统一接入的，而这个组件不支持 url 里的携带变量，要求运维发开升级组件难度很大，影响范围很大并且升级后稳定性无法评估。（或者 这是采购的第三方产品，且除软件外还包含专用防火墙硬件设备，厂家无法支持升级，需要购买新设备替换）"。

@x66 见过 es - elasticsearch #滑稽

说得难听点，你进了愿意招这样的同事的公司，而且你的 leader 默许（或支持）他的做法。

@avastms #37 RESTful 最重要的是对业务建模，一个资源对应后端一个业务模型，所以其实是能在大部分场景使用的。只是业务模型和前端 UI 并不完全对应，所以前端的时候一般会都套上一层 BFF 。

restful 只是个参考规范。 没有哪一条规定说要强制使用这个规范， 项目内统一规范不一定就是 restful

相对来说 post 当然比 get 更安全， 不说收缩引擎收录， 只是在各个网络节点至少不会留下痕迹。

用不用 restful ， 看你的 api 最终用户群， 如果 api 就是那么几个人用， 那就让 restful 见鬼去。

restful 大多数情况下会变得不伦不类，完全不如 detxxx deletexxx updatexxx

PTC 的 Thingworx 平台，自称 RESTful API ，只支持 POST ，我想做区分都不行，就这样吧

同 35 楼 ，全 post 接口用 Getxxx/Listxxx/Createxxx/Updatexxx 感觉很好，别人发个接口给你，从名字就能看出作用

需要通过链接分享的得用 GET ，例如筛选参数，分页等，不过前后端分离的也不存在这种情况了。
其他的如果不是 RESTFUL 风格的，都用 POST 没啥问题。

相信我，以后你跟这个同事合作过程中遇到的草台、山寨问题一定会比这更严重

@Wuuuu 筛选分为相等，排除，比较等形式，添加如 eq lt le gt ge 等标志可解，排序定义一个单独的参数即可。但我认为这只不过是一种接口设计的思路，实际上遵循的思想是 “尽可能少造轮子”，比如利用已存在的 HTTP 状态码代替自己定义错误信息，楼内也有人说了，非增删改查的复杂逻辑是很难用这种方式设计的，所以需要变通，比如当前端把筛选区做成一个很大的表单时，使用 POST 方法提交其实也很合理。

现在 get 也可以带 body ，get 和 post 不是一样安全？

@jfcai 见过 url 拼接 sql 的(ؓؒؒؑؑؖؔؓؒؐؐ⁼̴̀ωؘؙؖؕؔؓؒؑؐؕ⁼̴̀ )

RESTful 不是標準規範. 沒有遵守的必要.

JSON 有標準，標準文件是 ECMA-404.
PNG 有標準，標準文件是 RFC 2083.

RESTful 沒有標準規範. 不同的人搞 注冊登錄，會搞出千奇百怪的實現.