开发 API 的时候 http method 应该使用 PUT、PATCH、DELETE 等协议还得直接用 GET、POST
Inzufu · Lilac-milena · 248 天前 via Android · 12132 次点击这是一个创建于 248 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，
感觉前三者好像更规范些，不过好像很少见有用除 GET 和 POST 外协议的接口。
感觉前三者好像更规范些，不过好像很少见有用除 GET 和 POST 外协议的接口。
142 条回复 • 2024-03-28 22:03:05 +08:00
 |
1
seers 248 天前 via Android  3
我只说一点，大部分漏扫等保公司只会允许 GET/POST ，然后客户只会让你整改，当然自己玩随便
|
 |
2
cxsz 248 天前 1
我自己写的基本都是 get ，用起来方便，浏览器输入一下就行，公司规定是统一 post
|
 |
3
flyqie 248 天前 1
每隔一段时间就会出现这样的讨论，建议先左上搜索一下
看个人喜好和环境要求，我个人是 200 + post ，http_code != 200 问题肯定都是基础设施，跟我没关系。。 |
 |
4
0o0O0o0O0o 248 天前 8
|
 |
5
drymonfidelia 248 天前 1
|
 |
6
OutOfMemoryError 248 天前 1
@seers #1 +1 我们之前遇到一个“安全检测”就是这种要求，只好做了个变通方案，前端传 Header 到 nginx ，然后 nginx 处理一下发到后端
|
 |
9
Inzufu OP @seers @OutOfMemoryError 那看来还是用 GET POST 比较好，我个人感觉 PUT 、PATCH 、DELETE 这三个 methods 其实完全可以用 POST 代替。
|
 |
10
infun 248 天前 1
臆想的规范，现实世界比臆想世界复杂的多，抽象出来的方法很多时候都是脱裤子放屁
个人支持 get post 全包 |
 |
11
winterpotato 248 天前
🤣我们公司就不一样了，我们公司全部 get 数据通过 headers 发🤡
（开个玩笑） 当然遵循 restful 语义了 |
 |
12
securityCoding 248 天前 via Android
谁用 restful 我会暗自骂他傻 233
|
 |
13
agagega 248 天前
即使环境不能使用 PUT/PATCH/DELETE ，用 POST 模拟也是好的，或者就用 POST 表达发起某个事务的含义也完全没问题。怕的就是一股脑全用 GET ，创建订单也来个 GET ，这就无可救药了。
|
 |
14
luodan 248 天前
小白请教那些全用 GET 的同学一个问题，用 GET 不是大家都看得一清二楚了吗？
|
 |
15
Kumo31 248 天前
都用，RESTful API ，当然 RESTful API 的表达能力有缺陷，难以满足复杂业务场景，还需要结合 Google 的 Custom methods： https://google.aip.dev/136
|
 |
16
icy37785 248 天前 via iPhone 13
虽然别人问我接口怎么定义，我推荐 RESTful ，自己的项目只用 get 、post ，甚至看到 restful 还会发笑。
|
 |
17
siweipancc 248 天前 via iPhone
理论中：新建记录 post 返回 201 重定向到数据。
实际操作：返回 200 加个 ok 状态码。 问就是流程越简单 bug 越少。 |
 |
19
raycool 247 天前
post 一把梭吧
|
 |
20
zeromake 247 天前 via Android
我之前也想各种 put ，delete 用起来，然后客户端一对接说客户端框架封死了只能用 get ，post😂
|
 |
21
maymay5 247 天前
post 走全部
|
 |
22
lujiaxing 247 天前
视情况.
如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete... 如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API. 我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象 (如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层. 无论哪种其实都很恶心. |
 |
23
IdJoel 247 天前
DELETE PUT 多好用，要不 URL 整那老长多难受
对接的开发一眼就能看出来接口是干啥的，多直观啊？ |
 |
24
wangkun025 247 天前 via Android
我选择遵守 restful
|
 |
25
caomu 247 天前 via Android
|
 |
26
cmdOptionKana 247 天前
RESTful 是自找麻烦
|
 |
27
lff0305 247 天前
以前做项目见过的：
客户有奇葩的防火墙/负载均衡，对于 1. 非 Get Post 请求，高峰期不能保证 QOS ，要对 Get Post 让路 2. 非 2XX 返回值，会把 response 封装成类似 upstream error：<原始的 body> 而且可能 body 还会被截断 所以为了适应客户把项目做下去只能全部 GetPost ，用 200 返回，再把错误信息放在 Body 里面 |
|
28
cmdOptionKana 247 天前
RESTful 就是非常典型的学院派风格，理论上很优雅，很美，但实践中弊大于利，碍手碍脚。
|
 |
29
afxcn 247 天前
我们就用 RESTful 风格的，国内国外的项目也没遇到什么问题。
|
 |
30
aragakiyuii 247 天前 via Android 30
 |
 |
31
MrDarnell 247 天前 6
还是要走 restful 规范，现在很多公司规定 post 其实是一种负责人能力低下的表现，但碍于自尊心，拒绝承认
|
 |
32
layxy 247 天前
get,post,put,delete 四个都用,之前遇到过前端会吐槽说分不清接口,path 都一样容易调错
|
 |
33
IvanLi127 247 天前
反正我们严格遵守 RESTful ，等保和安全都过得去。我感觉这些请求方法都挺常见的
|
 |
34
wangtian2020 247 天前
都可以，市面上常见的两种接口风格
|
 |
35
proxychains 247 天前
GET 查询
POST 新增 |
 |
36
hash 247 天前
就像一楼说的,POST 一把梭是有他的原因的,但我仍然认为 POST 一把梭是傻逼
毕竟没有任何一个人一辈子只做政府外包 |
 |
37
jonsmith 247 天前
我用 get 和 post ，请求数据用 get 、更新用 post ，也见过全部用 post 的，但是全部 get 应该做不到。
|
|
38
proxychains 247 天前 1
GET 查询
POST 新增 PUT 修改 DELETE 删除 |
 |
39
bitmin 247 天前
大部分接口都很简单，省得想名字，/、/{id} GET POST DELETE PUT PATCH 对应增删改查多简单
复杂接口另说，当然是随机应变 还好我们接口都是自己用，除了老板没人指手划脚 |
 |
40
me1onsoda 247 天前
现实的情况很复杂，一个新增的过程可能也有查询删除修改
|
 |
41
Dlin 247 天前
有规范大家不使用，所有大家才会觉得碍手碍脚。
|
 |
42
cnevil 247 天前
http 标准中 delete 方法也不是给你这样用的吧
我觉得遵循国际标准比那什么 restful api 标准理由要充分的多。。 |
 |
43
jydeng 247 天前
我们用 gql
|
 |
44
shuax 247 天前
老夫只会 post json 一把梭。
|
 |
45
wanguorui123 247 天前
JAVA 里面 POST 最简单和通用，GET 简单的查询可以用用
|
 |
47
shyangs 247 天前 2
@MrDarnell
RESTful 是風格(style)，不是規範/標準(standard). 標準有標準文件，比如 JSON 的文件 ECMA-404 是由 ECMA 編寫. RESTful 是一份 2000 年的博士論文出來的風格，早就過時了，這位博士生可能連 XML(1998), JSON (2001) 都沒寫過，只好什麼都往網址上塞，這種過時風格被追捧太滑稽了. 連 JSON-RPC (2005) 都比 RESTful (2000) 新穎. |
 |
48
Van426326 247 天前
一楼说的对 我也不想改啊 等保过不了有啥办法
|
 |
49
echo0x000001 247 天前
很多人觉得 restful 不好用是因为没有工具，django 的 DRF 框架用起来不用太爽，节省很多代码。
|
 |
50
ShinichiYao 247 天前
get 也别要了，post 一把梭
|
 |
51
ben666 247 天前
get post put delete 都是常用的
本来开源网络性能测试仪 dperf 只支持 get ，有人提 issue 希望支持各种 method https://github.com/baidu/dperf/ |
 |
53
o562dsRcFqYl375i 247 天前
get -> 读
post -> 写 完事 |
 |
54
z1154505909 247 天前
我特么要喷一个腾讯,文档写的 get,例子也是 get,我用 get 请求返回我访问未知的 url,垃圾腾讯
|
 |
55
DOLLOR 247 天前 via Android
@proxychains
login 应该用哪个呢？ |
 |
56
qa2080639 247 天前
get 传值有类型问题 null false true 不好表示,所以我全用 post 传 json 一把梭 别人还在研究怎么定义接口我已经下班了
|
 |
57
Laobai 247 天前
只能 post 一把梭，否则扫描过不了
|
 |
58
sZiUp3ETjqDgSF2U 247 天前
查询用 get ，其他 post 一把嗦，运维淡疼在网关把其他都拦掉了。
|
 |
59
qbmiller 247 天前
2B 项目。老老实实 get post
|
 |
60
zxkxhnqwe123 247 天前 1
原来 RESTful
一段时间 GET POST 现在 POST |
 |
61
thinkershare 247 天前
这种重复提问，管理员应该禁止掉。
|
 |
62
Torpedo 247 天前
restful 不是一个好风格。因为实践里，我见到的每个自称 restful 风格的 api 都有不同。特别是一些模糊行为
|
 |
63
MrKrabs 247 天前
RESTful=野鸡
|
 |
64
zw1one 247 天前 1
post 一把梭真的很香，代码也很健壮，也很方便复制粘贴。省下来的时间可以摸鱼，活动下颈椎，让你身体精神保持健康。
|
 |
66
daiv 247 天前
@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 等等...) 各位大佬有什么建议吗? 这样是否合理. |
 |
67
leaflxh 247 天前
无非在于错误在哪处理
.then(res=>{ res.code === 200}) 还是 .catch(err) |
 |
68
olaloong 247 天前
稍微复杂点的业务用 RESTful 都是一团糟，毕竟一次调用里操作的可不止一个资源。硬套 RESTful 的话，要么按资源拆分请求，那复杂均衡、事物就糟了，要么在一个资源操作里隐性操作其他资源，时间一长就变成屎代码。
见过几个项目设计之初想用 RESTful ，最后都变成了特色 RESTful 的杂交项目。 |
 |
71
crackidz 247 天前
取决于你客户端开发的水平😂
|
 |
72
JenJieJu 247 天前
graphql ，前端自己撸
|
 |
73
9c04C5dO01Sw5DNL 247 天前
必须是考虑语义、Safe 和 Idempotent ，这些性质和 restful 无关，纯纯 rfc2616 中定义的啊。。。
|
 |
74
chendy 247 天前
全部 POST ，因为要兼容 ie ，put 之类的不敢用，get 有时候缓存了全麻
全部 200 ，因为对接的前端喜欢，反正写起来都一样 |
 |
75
momo24672 247 天前
GET 读
POST 创建 DELETE 删除 PATCH 更新 POST 一把梭的全是 SB/垃圾 |
 |
76
lesismal 247 天前
> POST 一把梭的全是 SB/垃圾
@momo24672 不选择 Restful 的人会越来越多, 注意, 我说的是"不选择", 而不是"放弃", 因为 Restful 本来就不是必选项. 另外, 别太自信了 |
|
78
proxychains 247 天前
|
 |
79
picone 247 天前
默认情况下，NginX 会认为 POST 等是非幂等请求，不会进行重试，POST 一把梭用户怎么解决这个问题
 |
 |
80
wjfz 247 天前
非要 post 也行，像#66 那种也还算清晰。
关键是错误处理，用 200 状态+错误码，前后端约定几十个错误码是一件及其傻逼的事情。 |
 |
81
WashFreshFresh 247 天前
@picone 用户会解决 手动狗头
|
 |
82
hxysnail 247 天前 2
大家是不是对 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 的，但接口五花八门。同一种数据，不同接口返回的格式有些字段名还不太一样，一不留神就被坑到。这就是垃圾。被坑的次数多了，别人就会抗拒跟他合作。 据我的观察，绝大部分程序员，特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了，不少人还喜欢浮于表面，夸夸其谈。说到底，“无规则不成方圆”，这么简单的道理，我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师，还在重复着开发一个垃圾接口，再写一份垃圾文档来描述这个垃圾接口的死路。 |
 |
83
zhwguest 247 天前
月经贴啊。。。。
|
 |
84
woodfizky 247 天前
合适就好，当你有选择的自由的时候都好说，反正没必要因为要强行套 restful 给自己上条条框框上枷锁，取其精华去其糟粕。
|
 |
85
ivvei 247 天前
RESTful 就是 SB 玩意。
|
 |
86
nekoneko 247 天前
|
 |
87
F7TsdQL45E0jmoiG 247 天前
擦，那些所谓的等保+安全公司基本快把 GET 都禁掉啦，已经堕落到全 POST
|
|
88
ivvei 247 天前
@hxysnail
五花八门： POST /Datas # 新增 POST /some/resource/path/_action PUT /Datas/{id} # 修改（整体替换） PUT /Datas/{id} # 修改（部分更新） 不要说别人就五花八门，说自己就是合理约定。 |
 |
89
jiayouzl 247 天前
按照规范肯定是 PUT 、PATCH 、DELETE.当然 get,POST 也可以,一切看自己需求.
|
 |
90
romisanic 247 天前
选择用不用一套规风格也能用出优越感来，神奇
更用此来评定与自己不同的别人是 SB/垃圾，这才是真正的 SB&垃圾啊 |
 |
91
ming7435 247 天前
X 银行安全团队只接受 GET / POST, 其他一律视为漏洞
|
 |
92
cxxnullptr 247 天前
建议学习一下 restful ，用起来比纯 POST 爽多了
|
|
95
momo24672 247 天前
用了 K8S 之后，其实更推崇谷歌这一套设计 https://cloud.google.com/apis/design/resources
|
 |
96
zhao8681286 247 天前
你们推荐 RESTful 有考虑过测试同学的感受模 默认 F12 fetch 一堆 Name 为 1 1 1 1 1 1 1 1 的请求。
 |
 |
97
jackerbauer 247 天前
post 吧，没那么多事，我们的为了实现业务的
|
|
98
icy37785 247 天前 via iPhone
@momo24672 #9 你一边说可以选择 RPC 或者 GraphQL 了一边又说 POST 一把梭的肯定是 SB 。
那你打算怎么用 GraphQL 。 |
|
99
hxysnail 247 天前 2
@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 而已。 “不要说别人就五花八门，说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是…… 今天想起要回这个贴，是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人，要换个接口，返回的数据字段没变。我的人就去换了，因为对方说接口一样，数据字段没变，他们就偷懒没验证。结果上生产就出了个小问题，因为数据有个字段结构不太一样…… 同一个字段，有一个接口是返回逗号分隔的字符串，另一个返回一个字符数组……理论上，同一种数据，不同的查询场景，返回的数据字段结构没必要不一样吧？这才是我强调的五花八门。 然后，我在自己项目的开发群里强调了范式规范，不知怎么发图片，直接贴我说的文字： 理论上，接口再垃圾，只要我们验证充分，问题肯定不会到生产上。 就算接口不好，最多也只是在开发阶段被坑，影响你的研发效率而已。 冤有头，债有主，谁坑你就去怼谁。 我以前经常跟你们强调，字段命名要前后一致，严禁五花八门，最近几次缺陷就是典型的案例。质疑别人前，我们自己要先做到这一点。 注意看， [质疑别人前，我们自己要先做到这一点。] 我们对自己的水平心里有数。 |
Select Language