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

[Inzufu]

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

[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 了?