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

[Inzufu]

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

[seers]

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

[cxsz]

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

[flyqie]

每隔一段时间就会出现这样的讨论，建议先左上搜索一下

看个人喜好和环境要求，我个人是 200 + post ，http_code != 200 问题肯定都是基础设施，跟我没关系。。

[0o0O0o0O0o]

你可以看看他们争得有多激烈：

/t/860356
/t/830030
/t/693907
/t/959602
/t/340607

与之齐名的还有 https://www.v2ex.com/t/1023997#r_14451382

[drymonfidelia]

@flyqie
@0o0O0o0O0o 还有这个 /t/899875

[OutOfMemoryError]

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

[Inzufu]

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

[Inzufu]

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

[Inzufu]

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

[infun]

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

[winterpotato]

🤣我们公司就不一样了，我们公司全部 get 数据通过 headers 发🤡

（开个玩笑）
当然遵循 restful 语义了

[securityCoding]

谁用 restful 我会暗自骂他傻 233

[agagega]

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

[luodan]

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

[Kumo31]

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

[icy37785]

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

[siweipancc]

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

[leo72638]

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

[raycool]

post 一把梭吧

[zeromake]

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

[maymay5]

post 走全部

[lujiaxing]

视情况.
如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete...
如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API.

我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象
(如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层.

无论哪种其实都很恶心.

[IdJoel]

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

[wangkun025]

我选择遵守 restful

[caomu]

@seers
@OutOfMemoryError 这啥道理？

[cmdOptionKana]

RESTful 是自找麻烦

[lff0305]

以前做项目见过的：

客户有奇葩的防火墙/负载均衡，对于
1. 非 Get Post 请求，高峰期不能保证 QOS ，要对 Get Post 让路
2. 非 2XX 返回值，会把 response 封装成类似 upstream error：<原始的 body> 而且可能 body 还会被截断

所以为了适应客户把项目做下去只能全部 GetPost ，用 200 返回，再把错误信息放在 Body 里面

[cmdOptionKana]

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

[afxcn]

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

[aragakiyuii]

[MrDarnell]

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

[layxy]

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

[IvanLi127]

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

[wangtian2020]

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

[proxychains]

GET 查询
POST 新增

[hash]

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

[jonsmith]

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

[proxychains]

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

[bitmin]

大部分接口都很简单，省得想名字，/、/{id} GET POST DELETE PUT PATCH 对应增删改查多简单

复杂接口另说，当然是随机应变

还好我们接口都是自己用，除了老板没人指手划脚

[me1onsoda]

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

[Dlin]

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

[cnevil]

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

[jydeng]

我们用 gql

[shuax]

老夫只会 post json 一把梭。

[wanguorui123]

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

[gongxuanzhang]

https://coolshell.cn/articles/22173.html

[shyangs]

@MrDarnell

RESTful 是風格(style)，不是規範/標準(standard).

標準有標準文件，比如 JSON 的文件 ECMA-404 是由 ECMA 編寫.

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

[Van426326]

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

[echo0x000001]

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

[ShinichiYao]

get 也别要了，post 一把梭

[ben666]

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

[flyqie]

@MrDarnell #31

`负责人能力低下`

醒醒，你是乙方。。

[o562dsRcFqYl375i]

get -> 读
post -> 写

完事

[z1154505909]

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

[DOLLOR]

@proxychains
login 应该用哪个呢？

[qa2080639]

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

[Laobai]

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

[sZiUp3ETjqDgSF2U]

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

[qbmiller]

2B 项目。老老实实 get post

[zxkxhnqwe123]

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

[thinkershare]

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

[Torpedo]

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

[MrKrabs]

RESTful=野鸡

[zw1one]

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

[julyclyde]

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

[daiv]

@raycool @maymay5 @shuax @ShinichiYao @Laobai @zxkxhnqwe123 @zw1one 如果全部用 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 等等...)

各位大佬有什么建议吗? 这样是否合理.

[leaflxh]

无非在于错误在哪处理

.then(res=>{ res.code === 200})
还是
.catch(err)

[olaloong]

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

[flyqie]

@leaflxh #67

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

[flyqie]

@flyqie #69
而且还能避免很多奇怪问题

[crackidz]

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

[JenJieJu]

graphql ，前端自己撸

[9c04C5dO01Sw5DNL]

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

[chendy]

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

[momo24672]

GET 读
POST 创建
DELETE 删除
PATCH 更新

POST 一把梭的全是 SB/垃圾

[lesismal]

> POST 一把梭的全是 SB/垃圾

@momo24672 不选择 Restful 的人会越来越多, 注意, 我说的是"不选择", 而不是"放弃", 因为 Restful 本来就不是必选项. 另外, 别太自信了

[flyqie]

@momo24672 #75

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

[proxychains]

@DOLLOR #55
GET
/login/username/md5(pwd)

[picone]

默认情况下，NginX 会认为 POST 等是非幂等请求，不会进行重试，POST 一把梭用户怎么解决这个问题

[wjfz]

非要 post 也行，像#66 那种也还算清晰。
关键是错误处理，用 200 状态+错误码，前后端约定几十个错误码是一件及其傻逼的事情。

[WashFreshFresh]

@picone 用户会解决 手动狗头

[hxysnail]

大家是不是对 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 的，但接口五花八门。同一种数据，不同接口返回的格式有些字段名还不太一样，一不留神就被坑到。这就是垃圾。被坑的次数多了，别人就会抗拒跟他合作。

据我的观察，绝大部分程序员，特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了，不少人还喜欢浮于表面，夸夸其谈。说到底，“无规则不成方圆”，这么简单的道理，我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师，还在重复着开发一个垃圾接口，再写一份垃圾文档来描述这个垃圾接口的死路。

[zhwguest]

月经贴啊。。。。

[woodfizky]

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

[ivvei]

RESTful 就是 SB 玩意。

[nekoneko]

@proxychains #38
PUT 全覆盖修改
PATCH 部分修改

[F7TsdQL45E0jmoiG]

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

[ivvei]

@hxysnail

五花八门：
POST /Datas # 新增
POST /some/resource/path/_action
PUT /Datas/{id} # 修改（整体替换）
PUT /Datas/{id} # 修改（部分更新）


不要说别人就五花八门，说自己就是合理约定。

[jiayouzl]

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

[romisanic]

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

[ming7435]

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

[cxxnullptr]

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

[momo24672]

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

[momo24672]

@flyqie 所以世界是草台班子

[momo24672]

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

[zhao8681286]

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

[jackerbauer]

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

[icy37785]

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

[hxysnail]

@ivvei #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 而已。

“不要说别人就五花八门，说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……

今天想起要回这个贴，是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人，要换个接口，返回的数据字段没变。我的人就去换了，因为对方说接口一样，数据字段没变，他们就偷懒没验证。结果上生产就出了个小问题，因为数据有个字段结构不太一样……

同一个字段，有一个接口是返回逗号分隔的字符串，另一个返回一个字符数组……理论上，同一种数据，不同的查询场景，返回的数据字段结构没必要不一样吧？这才是我强调的五花八门。

然后，我在自己项目的开发群里强调了范式规范，不知怎么发图片，直接贴我说的文字：

理论上，接口再垃圾，只要我们验证充分，问题肯定不会到生产上。
就算接口不好，最多也只是在开发阶段被坑，影响你的研发效率而已。
冤有头，债有主，谁坑你就去怼谁。
我以前经常跟你们强调，字段命名要前后一致，严禁五花八门，最近几次缺陷就是典型的案例。质疑别人前，我们自己要先做到这一点。

注意看， [质疑别人前，我们自己要先做到这一点。] 我们对自己的水平心里有数。

[lesismal]

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