开发 API 的时候 http method 应该使用 PUT、PATCH、DELETE 等协议还得直接用 GET、POST

[Inzufu]

如题，
感觉前三者好像更规范些，不过好像很少见有用除 GET 和 POST 外协议的接口。

[momo24672]

@icy37785 GraphQL 查询用的 GET ，其他用的是 POST ，没有 POST 一把梭啊。

[ktqFDx9m2Bvfq3y4]

@daiv 合理，我就是这么用的。

[icy37785]

@momo24672 #101 你这么说我就可以理解了，缺乏实践，难怪上面说出这么多暴论。

[IdJoel]

@zhao8681286 如果你这都看不懂，建议把 F12 关了

返回 200 和 500 一下就能区分出来，我感觉这效率应该更高才是

[momo24672]

@icy37785 我缺乏的不是实践，而是和 SB 共事的能力，用 POST 一把梭的同事第一天就要被开除了。
我就问你一个问题，你用 POST 一把梭是不是要保证所有的接口都幂等。

[ktqFDx9m2Bvfq3y4]

我不会使用 restful ，因为很多场景它没办法对付，反而让简单问题复杂化：

- 用户注销
- 忘记密码
- 软删除
- 获取某个东西，如果没有则自动创建一同返回
等等很多场景很难说哪个合适。

API 返回 404 到底是 url 无效还是数据找不到？返回 401 到底是会话无效了还是我没有此数据的访问权限？我觉得返回码只代表传输层就挺清晰的。

总起来说就是 restful 管了不该管的东西。

[shunia]

get/post 一把梭太香了，那些说能力的，get/post 也可以写的很规范啊，定义好路径和入参出参不就好了？非要整那么多鸟方法，你自己读代码的时候会去考虑这方法用了 put 所以怎么怎么着吗？不还是得一句话一句话得读？非要搁那扯半天，扯出啥优点出来了？除了增加 api 的复杂度有啥作用？

完了还硬要嫌弃别人水平太差，甚至还要 diss 前端，港真有点无语。。。

知道你牛逼，一个简单的资源增删查改，让前端调三次 http 就是老牛逼老规范水平老高了！

[lesismal]

@momo24672 #101

> GraphQL 查询用的 GET ，其他用的是 POST ，没有 POST 一把梭啊。

看样子我误解你一半, 看样子至少你不是说"不用 Restful 都是 sb", 你只是说"全 Post 一把梭是 sb"
但 post 大于 get, 甚至这只是协议命令的一点定义区别, get 也可以带 body, 所以 get post 在实际使用上区别没太大影响. 但如果这样的话, #101 和 #75 就有点自相矛盾了

[momo24672]

@lesismal RFC7231 不支持 GET 带 Body （语义上不合理），而且大部分的库应该也不支持这样做。
是的，我说的是 POST 一把梭的情况，另外跨域的情况下 POST 是两个数据包，总之 POST 一把梭肯定不太行。

[icy37785]

@momo24672 #105 我的意思是，如果你要说 POST 一把梭的都是 SB ，你就得把 GraphQL 给一棒子打死，因为 GraphQL 实践里，如果真拿 GET 去查询，会产生的问题很多，把产生的问题全部解决，复杂度是几何倍数上涨的，在实践里只有 POST 一把梭是成本最能接受的。
甚至在 RPC-JSON 的实践里也有类似的情况。
我至始至终不能理解的是，你一边说可以选择 RPC 或者 GraphQL 了一边又说 POST 一把梭的肯定是 SB 这件事。
而不是不能理解你说 POST 一把梭的都是 SB 这件事。

[deno2h]

我们公司开始是标准 restful ，后来被银行客户教育了，客户只接受 GET 和 POST ，就都改了

[lesismal]

@momo24672 可别提 HTTP RFC 了,HTTP 是我见过的最 sb 的最婊子的协议, 它本身的设计就侵入了应用层, 所以才有几天这种局面: 用户不只是要处理自己业务层的错误码,还要考虑 HTTP 错误码相关的各种细节, 以使用 Restful 的情况更甚! Websocket 甚至还继承了一些协议设计的糟粕,比如 ws 自己的那些错误码, 作为定义相当于传输层的协议, 自己搞这么多画蛇添足简直是垃圾. 当然 ws 本身也是为了弥补 HTTP 自己这个太监协议, 一丘之貉.

> 跨域的情况下 POST 是两个数据包

跨域情况 POST 是两个数据包是指什么?协议交互角度讲, 一个 request 是一个协议包, 一个 response 也是一个协议包, 两个数据包是指几次请求或者具体是指什么?

[way2create]

之前就用 get/post 按路由分 也用过 Restful 但我比较懒 具体情况具体分析呗 这又不是强制规范吧 如果团队规范让我用 Restful 也 OK 只用 get 怕是不太行

[momo24672]

@lesismal 两个数据包是我记反了，PATCH/PUT 的接口跨域是要有 OPTIONS 预检请求的

[lesismal]

@momo24672 HTTP 协议本身被设计成了一坨屎, 但毕竟是属于开天辟地, 不完善情有可原. 但因为它是互联网基石, 所以不好升级迭代, 历史兼容导致了屎堆越来越多越来越大. Restful 就是屎上雕花, 奈何多数人都是有的用就跟着学和用, 根本不考虑是不是好东西. Post 一把梭的人都是在化繁为简, 用奥卡姆剃刀让互联网更美好. 这帖子里已经有人提了 等保, 银行, 以前帖子里有更具体的案例

希望那些被 HTTP 、或者被 Restful 毒害了的小白少点人云亦云, 不要因为自己曾经投入了学习就被沉没成本效应搞得无法自拔. 就技术论技术, 行业先驱随便搞啥出来都会有一波群众被带偏, 也不能怪谁学错了方向, 所以也就不要说谁是 sb 了, 自己多思考能分辨好坏才是最好的

[IMengXin]

公司的全 post ，漏扫认为除了 get post 就是不安全，要求整改，甚至有些页面跳转带了 token 字样也要求整改，不能使用 token

[momo24672]

@lesismal 我完全不能理解把 POST 一把梭解释为化繁为简

[iOCZS]

看起来美好，但是加了很多心智负担和认知沟壑

[kim01]

个人喜欢梭哈 post ，
1 、中小公司人员参差不齐，
2 、前后端一把梭，框架一把撸
3 、特殊条件仅允许 get 、post

[lesismal]

@momo24672 #117
正如我前面讲的, HTTP 本身的设计侵入了用户自己的应用层协议, 它既负责数据传输, 又自定义了太多应用层相关的协议, 如果只做静态资源文件服务之类的特定简单可控的场景, 那么它自己相当于是应用协议, 这样设计或者这样使用倒也凑合, 无可厚非.
单就 HTTP 还有一些其他的我在其他帖子里有聊过, 比如 HTTP 自己既有 Method, 又有 Router, 然而一个协议交互主要就是表明亮点: 要干什么, 干这个需要什么. 这两点, 主要体现在协议头和包体. 这世界上可不只是有 web http 的开发需求, 其他领域自定义的协议通常都是比这简化的, 主要满足这两点——协议头和包体, 比如 RPC. 除了 HTTP, 我在其他领域比如 IM, 游戏, 音视频, 各种领域的协议, 我几乎没见到过协议头自己也分两层的: 一层 Method 另一层 route. 而且你认真地想一想, Method 分这么多真的有必要吗?没有它就解决不了现实问题了吗?显然不是!

复杂的现代业务需求, 应用层自己要做很多业务分支状态码, 如果同时要兼顾 HTTP 自己的, 要多思考一层, 比如这里争论的到底是用 GET 还是 POST PUT DELETE, 有的团队有的开发者还要琢磨到底是直接按 HTTP 的状态码比如 403 还是统一用 HTTP 200+自己应用层的错误码. POST 一把梭的方案, 主要就是屏蔽了这些 HTTP 自己的东西, 业务集中考虑自己业务层的协议设计, 这既符合分层原则, 也减少了兼顾两个协议层次的设计的耦合, 所以这是简化复杂度.


具体的可能需要你实际体验一段时间以及深入思考下才能体会到.
如果还是无法理解, 那建议也不要随便下结论去武断地认为是别人 sb, 也需要反思下是不是自己当下见过的世界是不是有点窄到只了自己暂时狭隘了...