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

我只说一点，大部分漏扫等保公司只会允许 GET/POST ，然后客户只会让你整改，当然自己玩随便

我自己写的基本都是 get ，用起来方便，浏览器输入一下就行，公司规定是统一 post

每隔一段时间就会出现这样的讨论，建议先左上搜索一下看个人喜好和环境要求，我个人是 200 + post ，http_code != 200 问题肯定都是基础设施，跟我没关系。。

你可以看看他们争得有多激烈： /t/860356 /t/830030 /t/693907 /t/959602 /t/340607与之齐名的还有 www.hesudu.com/t/1023997＃r_14451382

还有这个 /t/899875

＃1 +1 我们之前遇到一个“安全检测”就是这种要求，只好做了个变通方案，前端传 Header 到 nginx ，然后 nginx 处理一下发到后端

我一般也是 POST 用的多一些，状态码就是200 、401 、403 、404 ，其他的状态码还真没用过。

GET 请求一般直接把参数放在 url 里，个人总感觉不是很安全。

那看来还是用 GET POST 比较好，我个人感觉 PUT 、PATCH 、DELETE 这三个 methods 其实完全可以用 POST 代替。

臆想的规范，现实世界比臆想世界复杂的多，抽象出来的方法很多时候都是脱裤子放屁个人支持 get post 全包

🤣我们公司就不一样了，我们公司全部 get 数据通过 headers 发🤡（开个玩笑）当然遵循 restful 语义了

谁用 restful 我会暗自骂他傻 233

即使环境不能使用 PUT/PATCH/DELETE ，用 POST 模拟也是好的，或者就用 POST 表达发起某个事务的含义也完全没问题。怕的就是一股脑全用 GET ，创建订单也来个 GET ，这就无可救药了。

小白请教那些全用 GET 的同学一个问题，用 GET 不是大家都看得一清二楚了吗？

都用，RESTful API ，当然 RESTful API 的表达能力有缺陷，难以满足复杂业务场景，还需要结合 Google 的 Custom methods： google.aip.dev/136

虽然别人问我接口怎么定义，我推荐 RESTful ，自己的项目只用 get 、post ，甚至看到 restful 还会发笑。

理论中：新建记录 post 返回 201 重定向到数据。实际操作：返回 200 加个 ok 状态码。问就是流程越简单 bug 越少。

＃14 要安全肯定要 https 。你只用 http 的话，用什么请求方式没本质区别，懂拦截请求的人不会不懂看 body 里的数据

post 一把梭吧

我之前也想各种 put ，delete 用起来，然后客户端一对接说客户端框架封死了只能用 get ，post😂

post 走全部

视情况.如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete...如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API.我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象(如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层.无论哪种其实都很恶心.

DELETE PUT 多好用，要不 URL 整那老长多难受对接的开发一眼就能看出来接口是干啥的，多直观啊？

我选择遵守 restful

这啥道理？

RESTful 是自找麻烦

以前做项目见过的：客户有奇葩的防火墙/负载均衡，对于1. 非 Get Post 请求，高峰期不能保证 QOS ，要对 Get Post 让路2. 非 2XX 返回值，会把 response 封装成类似 upstream error：<原始的 body> 而且可能 body 还会被截断所以为了适应客户把项目做下去只能全部 GetPost ，用 200 返回，再把错误信息放在 Body 里面

RESTful 就是非常典型的学院派风格，理论上很优雅，很美，但实践中弊大于利，碍手碍脚。

我们就用 RESTful 风格的，国内国外的项目也没遇到什么问题。

还是要走 restful 规范，现在很多公司规定 post 其实是一种负责人能力低下的表现，但碍于自尊心，拒绝承认

get,post,put,delete 四个都用,之前遇到过前端会吐槽说分不清接口,path 都一样容易调错

反正我们严格遵守 RESTful ，等保和安全都过得去。我感觉这些请求方法都挺常见的

都可以，市面上常见的两种接口风格

GET 查询POST 新增

就像一楼说的,POST 一把梭是有他的原因的,但我仍然认为 POST 一把梭是傻逼毕竟没有任何一个人一辈子只做政府外包

我用 get 和 post ，请求数据用 get 、更新用 post ，也见过全部用 post 的，但是全部 get 应该做不到。

GET 查询POST 新增PUT 修改DELETE 删除

大部分接口都很简单，省得想名字，/、/{id} GET POST DELETE PUT PATCH 对应增删改查多简单复杂接口另说，当然是随机应变还好我们接口都是自己用，除了老板没人指手划脚

现实的情况很复杂，一个新增的过程可能也有查询删除修改

有规范大家不使用，所有大家才会觉得碍手碍脚。

http 标准中 delete 方法也不是给你这样用的吧我觉得遵循国际标准比那什么 restful api 标准理由要充分的多。。

我们用 gql

老夫只会 post json 一把梭。

JAVA 里面 POST 最简单和通用，GET 简单的查询可以用用

coolshell.cn/articles/22173.html

RESTful 是風格(style)，不是規範/標準(standard).標準有標準文件，比如 JSON 的文件 ECMA-404 是由 ECMA 編寫.RESTful 是一份 2000 年的博士論文出來的風格，早就過時了，這位博士生可能連 XML(1998), JSON (2001) 都沒寫過，只好什麼都往網址上塞，這種過時風格被追捧太滑稽了. 連 JSON-RPC (2005) 都比 RESTful (2000) 新穎.

一楼说的对 我也不想改啊 等保过不了有啥办法

很多人觉得 restful 不好用是因为没有工具，django 的 DRF 框架用起来不用太爽，节省很多代码。

get 也别要了，post 一把梭

get post put delete 都是常用的本来开源网络性能测试仪 dperf 只支持 get ，有人提 issue 希望支持各种 method github.com/baidu/dperf/

＃31负责人能力低下 醒醒，你是乙方。。

get -> 读post -> 写完事

我特么要喷一个腾讯,文档写的 get,例子也是 get,我用 get 请求返回我访问未知的 url,垃圾腾讯

login 应该用哪个呢？

get 传值有类型问题 null false true 不好表示,所以我全用 post 传 json 一把梭 别人还在研究怎么定义接口我已经下班了

只能 post 一把梭，否则扫描过不了

查询用 get ，其他 post 一把嗦，运维淡疼在网关把其他都拦掉了。

2B 项目。老老实实 get post

原来 RESTful一段时间 GET POST现在 POST

这种重复提问，管理员应该禁止掉。

restful 不是一个好风格。因为实践里，我见到的每个自称 restful 风格的 api 都有不同。特别是一些模糊行为

RESTful=野鸡

post 一把梭真的很香，代码也很健壮，也很方便复制粘贴。省下来的时间可以摸鱼，活动下颈椎，让你身体精神保持健康。

PUT/PATCH/DELETE 的 URI 是一个目标对象； POST 的 URI 是一个 handler ，参数是一个对象

如果全部用 Post, 那么路径如何设计更合理?创建（ Create ）: POST /api/v1/user/create更新（ Update ）: POST /api/v1/user/update读取（ Read ）: POST /api/v1/user/read 列表（ List ）: POST /api/v1/user/list操作（ Operate ）: POST /api/v1/users/operate (Delete, HardDelete, Restore, Copy 等等...) 各位大佬有什么建议吗? 这样是否合理.

无非在于错误在哪处理.then(res=>{ res.code === 200}) 还是.catch(err)

稍微复杂点的业务用 RESTful 都是一团糟，毕竟一次调用里操作的可不止一个资源。硬套 RESTful 的话，要么按资源拆分请求，那复杂均衡、事物就糟了，要么在一个资源操作里隐性操作其他资源，时间一长就变成屎代码。见过几个项目设计之初想用 RESTful ，最后都变成了特色 RESTful 的杂交项目。

＃67个人觉得 post+200 一把梭主要是为了分层，走到 catch 是基础设施问题，其他的是业务问题。

＃69而且还能避免很多奇怪问题

取决于你客户端开发的水平😂

graphql ，前端自己撸

必须是考虑语义、Safe 和 Idempotent ，这些性质和 restful 无关，纯纯 rfc2616 中定义的啊。。。

全部 POST ，因为要兼容 ie ，put 之类的不敢用，get 有时候缓存了全麻全部 200 ，因为对接的前端喜欢，反正写起来都一样

GET 读POST 创建DELETE 删除PATCH 更新POST 一把梭的全是 SB/垃圾

POST 一把梭的全是 SB/垃圾 不选择 Restful 的人会越来越多, 注意, 我说的是"不选择", 而不是"放弃", 因为 Restful 本来就不是必选项. 另外, 别太自信了

＃75我记得 bilibili 部分项目貌似最后就是 post 一把梭。

＃55 GET/login/username/md5(pwd)

默认情况下，NginX 会认为 POST 等是非幂等请求，不会进行重试，POST 一把梭用户怎么解决这个问题
非要 post 也行，像＃66 那种也还算清晰。关键是错误处理，用 200 状态+错误码，前后端约定几十个错误码是一件及其傻逼的事情。

用户会解决 手动狗头

大家是不是对 Restful 有什么误解，Restful 多出来好几种 method ，是 GET/POST 的超集，不存在能力比 GET/POST 更弱吧？我维护的项目，采用 Restful 协议，迭代了好多年，没发现有什么坑啊比如，一个资源普通的增删改，能有什么问题？POST /Datas ＃ 新增GET /Datas/{id} ＃ 查询PUT /Datas/{id} ＃ 修改（整体替换）PUT /Datas/{id} ＃ 修改（部分更新）DELETE /Datas/{id} ＃ 删除对于特殊的业务逻辑，我们约定好一个在某个资源上做的一个动作，范式如下：POST /some/resource/path/_action举个例子，我们想让数据支持软删除：POST /Datas/{id}/_markDeleted ＃ 软删除（打标记但数据不删）再举个例子，搜索数据集合，Body 传一个 Filter （比如 Name 符合某个正则表达式）：POST /Datas/_search{ "Filter": { "Name": { "$regex": "abc" } }}最后一个例子，某条数据记录想发一条通知出来：POST /Datas/{id}/_notify迭代了这么多年，没发现有什么所谓的业务逻辑套不进去的问题啊。还看到一个说法说，Restful 需要写好多个接口，然后再让前端来整合？这不是典型的接口 [粒度] 问题嘛……站在后端的角度，接口粒度合理拆细是可以，难不成来个场景你加个接口刷一刷存在感吗？别人我不知道，我对手下的后端的要求就是合理地细，让前端可以灵活组合完成特定、个性化的业务场景。站在项目统筹管理的角度，如有某种组合很常用，你让前端自己一遍遍地去拼接也不合理吧？这个时候不就提供一种粒度更粗，但更固化的接口出来吗？这样双方不都得到满足吗？同样别人我不知道，我对手下的前端的要求，就是接口不合理，需要不断重复组合的逻辑，就要反馈给后端。然后一起消除重复性。总结：①后端接口粒度在合理的前提下，尽量细；②对于常用组合，再封装更固化和个性化的粗粒度接口。还有一个问题，说前端框架封死了只能 GET/POST……挖槽，前端垃圾关你啥事？关 Restful 啥事？能 diss 他就 diss 他，不能 diss 他的就捏着鼻子接受吧。还有人提到，说客户公司只允许用 GET/POST ，怎么说呢？都做乙方了，当然没办法了，甲方说啥就是啥……但这是你还是有办法在 POST 方法的基础上，自行定义一套给 Restful 类似的协议，无法是把原本用 Method 来表达的信息搬到 body 里而已。举个例子：POST /Datas/{id}{ "Action": "UPDATE", "Data": ……}因此，重点不是 Restful or GET/POST ，重点是接口要满足一套统一而且规范的范式。我同意有人提到说 GET 、POST 是负责人不负责任的做法。就 POST 请求，然后 path 爱怎么定就怎么定，数据爱怎么传就怎么传，最终一定是座代码屎山。举个例子，我合作过的项目，就纯 POST 的，但接口五花八门。同一种数据，不同接口返回的格式有些字段名还不太一样，一不留神就被坑到。这就是垃圾。被坑的次数多了，别人就会抗拒跟他合作。据我的观察，绝大部分程序员，特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了，不少人还喜欢浮于表面，夸夸其谈。说到底，“无规则不成方圆”，这么简单的道理，我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师，还在重复着开发一个垃圾接口，再写一份垃圾文档来描述这个垃圾接口的死路。

月经贴啊。。。。

合适就好，当你有选择的自由的时候都好说，反正没必要因为要强行套 restful 给自己上条条框框上枷锁，取其精华去其糟粕。

RESTful 就是 SB 玩意。

＃38 PUT 全覆盖修改PATCH 部分修改

擦，那些所谓的等保+安全公司基本快把 GET 都禁掉啦，已经堕落到全 POST

五花八门：POST /Datas ＃ 新增 POST /some/resource/path/_actionPUT /Datas/{id} ＃ 修改（整体替换）PUT /Datas/{id} ＃ 修改（部分更新）不要说别人就五花八门，说自己就是合理约定。

按照规范肯定是 PUT 、PATCH 、DELETE.当然 get,POST 也可以,一切看自己需求.

选择用不用一套规风格也能用出优越感来，神奇更用此来评定与自己不同的别人是 SB/垃圾，这才是真正的 SB&垃圾啊

X 银行安全团队只接受 GET / POST, 其他一律视为漏洞

建议学习一下 restful ，用起来比纯 POST 爽多了

可以选择不使用 Restful ，RPC 或者 GraphQL 都可以。但是 POST 一把梭的肯定是 SB

所以世界是草台班子

用了 K8S 之后，其实更推崇谷歌这一套设计 cloud.google.com/apis/design/resources

你们推荐 RESTful 有考虑过测试同学的感受模 默认 F12 fetch 一堆 Name 为 1 1 1 1 1 1 1 1 的请求。

post 吧，没那么多事，我们的为了实现业务的

＃9 你一边说可以选择 RPC 或者 GraphQL 了一边又说 POST 一把梭的肯定是 SB 。那你打算怎么用 GraphQL 。

＃88 咱不杆哈①部分修改那里，我把 Method 打错了，应该是 PATCH②我不知道前面那里那个地方五花八门了。拿我们自定义的 action 部分来说，我们至少保障 action 是一致的，想搜索数据就调_search 接口，比如：- POST /Datas/_search- POST /Hosts/_search- POST /BusinessSystems/_search再比如，我们所有软删除数据接口，action 都是_markDeleted ，不会 A 叫 softDelete ，B 叫 softRemove- POST /Datas/{id}/_markDeleted- POST /Hosts/{id}/_markDeleted- POST /BusinessSystems/{id}/_markDeleted/some/resource/path 只是想表达有些 action 是在数据集上，比如/Datas ；有些 action 是在单个数据记录上，比如/Datas/{id}；甚至有些 action 是在子数据上，比如/Datas/{id}/SubDatas/{subid}。哪里五花八门了？你不会看到/some/resource/path 跟/Datas 不一样就觉得五花八门吧……我通篇都在强调统一一致的范式，而不是在强调就应该采用跟我一样的思路。我不在乎范式是什么，我反对前后不一致，没有任何规则的 POST 而已。“不要说别人就五花八门，说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……今天想起要回这个贴，是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人，要换个接口，返回的数据字段没变。我的人就去换了，因为对方说接口一样，数据字段没变，他们就偷懒没验证。结果上生产就出了个小问题，因为数据有个字段结构不太一样……同一个字段，有一个接口是返回逗号分隔的字符串，另一个返回一个字符数组……理论上，同一种数据，不同的查询场景，返回的数据字段结构没必要不一样吧？这才是我强调的五花八门。然后，我在自己项目的开发群里强调了范式规范，不知怎么发图片，直接贴我说的文字：理论上，接口再垃圾，只要我们验证充分，问题肯定不会到生产上。就算接口不好，最多也只是在开发阶段被坑，影响你的研发效率而已。冤有头，债有主，谁坑你就去怼谁。我以前经常跟你们强调，字段命名要前后一致，严禁五花八门，最近几次缺陷就是典型的案例。质疑别人前，我们自己要先做到这一点。注意看， [质疑别人前，我们自己要先做到这一点。] 我们对自己的水平心里有数。

我就很喜欢 post 一把梭.聊点具体的, 你没有限定范围, 就以 api 为例, 请问 post 一把梭哪里 sb 了?