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

[Inzufu]

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

[momo24672]

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

[Chad0000]

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

[icy37785]

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

[IdJoel]

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

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

[momo24672]

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

[Chad0000]

我不会使用 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, 也需要反思下是不是自己当下见过的世界是不是有点窄到只了自己暂时狭隘了...

[lesismal]

@momo24672 期待各位反对 POST 一把梭的早日加入 POST 一把梭大家庭!

[zhao8681286]

@IdJoel 这个是 4 个不同的接口 。。。用 path 传参 你现在能给我第一眼给我找出具体啥是啥吗？

[unnamedhao]

JSON-RPC 了解下

[ljsh093]

@Inzufu #8 暴露在历史记录里

[willchen]

公司用就 get post 吧，如果开源项目还是 restful 一点好

[yooomu]

基本只用 GET 、POST ，强行 Restful 只会给自己找麻烦，表达能力太弱。我定义接口都是用动词描述，比如/books/getById ，一眼就知道做什么用的

[IdJoel]

@zhao8681286 https://imgur.com/Sm6VFcL 咱能不能稍微动动脑呢？

[Dogtler]

虽然是有 rest 规范，但是大部分遇到都是一个 post 搞定所有。

[Nich0la5]

我司为了解决一楼的问题，统一走 POST 然后在 header 里面有一个 relType:PUT/DELETE/POST 的标识，后端业务处理前先转一下

[knives]

@Nich0la5 以及各位，X-HTTP-Method-Override 了解一下 ？:doge https://zhuanlan.zhihu.com/p/128052857

[hafuhafu]

做那种 openAPI 适合用 restful 那一套，比较清晰优雅，别人调用封装也舒服。
写业务确实 get 、post 包圆比较好。

[luozic]

看资源粒度和接口定义方式，不过为了日志清晰和安全，只用 get post 作为 http 请求，但是在 controller 那里根据操作转义

[luozic]

@luozic 并且这也是为了方便改 cqrs ，读写分离等后期优化

[Inzufu]

@thinkershare 我搜了一下 restful 这个关键词，最近一年左右只有我这一个帖子。
而且这种习惯性问题也不像理论性问题，每一个帖子中都会有好的想法可供参考，而且也会随时间的推移而产生更好的答案。
所以我感觉我这贴算不上无意义

[xiangyuecn]

既然问了，那就

GET + body

[dyv9]

@lesismal 有些新手设计时就没考虑并发修改，一个表只有一个 update SQL ，也不考虑一些操作实际上只修改几个相关栏位，通通给你把所有非主键栏位放在 set 后面，并发场景数据轻轻地给搞错了。

[july1995]

@Inzufu #134 我觉得你说的对,这种帖子随着时间的推移,会有不同的答案. 不算重复.

[Nich0la5]

@knives #130 感谢 虽然我们那个代码用了好多年了懒得动了

[YuuuuuuH]

@lujiaxing 如果我没理解错的话，你想要表达的业务语义是要查询一个组织内部的所有用户关系，那么接口应该是这样的

POST api/v3/organizations/{OrganizationID}/relationships

[lujiaxing]

@YuuuuuuH 某个人在某个组织内的用户关系

[YuuuuuuH]

@lujiaxing 那应该是这样

POST api/v3/people/{person_id}/relationship?organization={organization_id}

[lujiaxing]

@YuuuuuuH 还不如 /people/getPersonRelInOrg?orgid=&personid= 来的简单明了。