如何看待：不遵循 restful_api 设计，所有的 api 使用 POST 提交

[ikaiguang]

• GET （ SELECT ）：从服务器取出资源（一项或多项）。
• POST （ CREATE ）：在服务器新建一个资源。
• PUT （ UPDATE ）：在服务器更新资源（客户端提供改变后的完整资源）。
• PATCH （ UPDATE ）：在服务器更新资源（客户端提供改变的属性）。
• DELETE （ DELETE ）：从服务器删除资源。

把所有的 API 都设计为 POST 提交方式，你们是如何看待的。

懒？

[ieiayaobb]

当 GET 超过了 URL 限制，只能用 POST 替代

[qq292382270]

我觉得挺好的. 因为我的客户大部分只会 post .

[mokeyjay]

没啥好看待的，有些人只知道获取资源用 GET，其他所有情况用 POST
至于用这种还是用 restful 看具体情况谁话语权大了

[Cyron]

无所谓，文档写好就行了

[wingoo]

restful 并不是标准, 不用就会出错

[hnbcinfo]

严格遵循 restful 我觉得不现实，也不一定就好。我一般就用 Get Post。读操作 get，写操作 post，当然也会偶尔有例外。只要文档写好，有一套规则，别随便用就好。

[rockyou12]

远古时代，http 的 get 请求会被各种服务商做缓存，所以请求都用 post 还算合理的设计。现在反正都 https 了，不存在了

[mcfog]

不如何看待，工作那么多年了就没见过纯按标准来的 PATCH 或者 PUT 方法的接口

顺便，楼主你的理解也并不准确，PUT 同样适用于新增

[learnshare]

没有最佳实践，不专业才是正常的，多数上层应用不遵守协议也能凑合运行嘛

@rockyou12 也不知道谁遇到过这个问题，并把他的垃圾经验推广开了

[ikaiguang]

@mcfog

嗯呢。上面的理解，摘自“ 阮一峰”的。

[ikaiguang]

@Cyron
@qq292382270

我们的项目都是 post，不使用 get.

为了贪图方便

[est]

挺好的。

real world 如果只能用这 5 种方式操作资源简直是智障设定。比如我登出操作，如何对应这 5 种资源操作？

[mcfog]

@est 可以当然是可以的，虚拟资源虚拟万物即可
DELETE /session/current 或者 /session/:sid

[baiyi]

不赞成所有的 API 都是用 POST

但同样不赞成将 HTTP 方法对应 CRUD，例如说 POST：确实有“创建新资源”的语义，但是它还有“向数据处理过程提交数据块”的语义，这个“ data-handling process ”描述的太模糊了，所以 POST 方法完全可以替代 PUT、DELETE、PATCH，就像 HTML 的 form 标签，只支持 GET、POST，也完全符合语义的。在《 RESTful Web APIs 》这本书里叫它“ whatever ”......

所以我个人更倾向于用业务逻辑的安全性、幂等性来定义 API 该是用哪种方法。

举个例子：转账，使用 CRUD 就很难去对应，有的可能会用 PUT，因为修改了两个账户的余额信息，有的用 POST，但可能是强行将主体对象从账户转为转账记录这样的资源上，就会让人感觉很混乱。

但如果使用幂等性来判断就很简单，PUT 幂等，POST 不幂等，那转账，肯定是不幂等的。按照这个思路换个例子：修改用户余额，可能这样的场景比较少，但主要是为了说明。这个就应该使用 PUT，应为它是幂等的。

[beyond99]

@mcfog 这种为了 restful 而 restful 的方式有什么意义？只会让接口更难懂

[baiyi]

@mcfog #13 不建议这样构建资源

对于用户来说，POST “/user/logout ” 比 DELETE “/session ” 更容易理解，用户需要额外的去理解 session 这个资源的意义

[ArJun]

所谓的规矩就是用来打破的，且意义上的 restful 都用 POSt 请求方式并没有什么影响

[wu67]

post 没什么毛病啊. 上面也说了 get 会被缓存, 这是其一; 统一 post 的话, 前端 /客户端封装请求方法也简洁很多, 不会出现 新来的菜鸡实习生搞不清楚为什么出错到处发问(笑) 的情况...

[hmzt]

挺方便的,甚至一开始就不该设计那么复杂

[Vegetable]

挺方便的,信息更集中,通过 json 传递的参数带基本类型,减少犯错空间.比如 querystring 的 a=1&a=2 这种设计,很容易让新手犯错.

你可能觉得不遵守规范是不对的,实际上这就是一种权衡,严格遵守 restful 很难,复杂业务下,只要有一份规则,大家共同遵守就可以,没有圣经.