你们在设计 restful api 时会用 put 和 delete 吗？

[red13]

我一直用 get 和 post ，完全可以满足需求，我不知道是否有业务场景是使用 put 和 delete 会带来好处的，我能想到的就是可以一眼看出接口的作用是什么。使用 put 和 delete 在功能性、安全性、性能上能带来好处吗？

[seedhk]

刚毕业那几年会，PUT DELETE POST GET 分的清清楚楚。现在直接 GET POST 一把嗦

[momo2789]

首先 RESTful 约定 URL 表示资源（名词），HTTP Method 表示动作（动词）。所以 post /deleteUser 这种 URL 其实把“动词”塞进了路径，不算是纯正的 RESTful 风格。

功能性上来讲假如上了一定规模，需要用上 API Gateway 。使用标准方法可以让它们自动识别请求意图，从而自动启用缓存、权限、幂等、限流等功能。全用 POST ，那么安全审核无法直接区分这个 POST 是“新增”还是“删除”，只能靠解析 URL 或 Body ，这样更复杂印象性能且容易漏。

RESTful 不是强制约束，也没有标准。所以找到一个符合公司团队都能一致接受就都可以。当然我还是更推荐使用 PUT 和 DELETE ，可以少走一些弯路。

[BlueSkyXN]

一般不会

[maocat]

直接 post 一把梭哈

[jamesxu]

国内好多政企部署要求禁用 PUT 、DELETE

[Leeeeex]

我们公司的项目在最早的开发手上做过 put 和 delete ，但是后来就没人写了，在搜接口的时候同一个接口出来好几个，第一次看的时候还好奇为啥几个接口名一样项目没报错。
接口名字做好语义化就行了，不需要写固定的方法名

[BernieDu]

https://app.swaggerhub.com/apis/portainer/portainer-ee/2.19.3#/ 这是 portainer api ，/custom_templates/{id} 同时有 get , put , delete, 这种场景蛮多的，对服务端来说不用命三个名，对客户端来说一看就知道啥意思，封装方法的时候好封，大家都开心。 单纯满足需求的话 get 和 post 肯定是能满足

[flytsuki]

会用,但项目刚上线接口容易调不通 最好还是只用 get 和 post

[izneogoud]

产生新内容时用 post ，幂等的更新操作时用 put 。

[EastLord]

项目里没用，所以我也不用

[loading]

如果写下一个，我准备都用 POST ，GET 也不用了。

[pusheax]

之前出过好几个与 PUT 相关的安全漏洞，如 tomcat 的 CVE-2017-12615 和 IIS 的 Webdav 漏洞。
虽说这更多还是应用程序设计的问题，但搞的安全人员有点 PTSD 。水平较差的漏洞扫描器或者入侵检测设备，看到 PUT 就喜欢报安全问题。
因而会有一刀切要求禁用 PUT 的情况。

[irisdev]

运维和信息安全不让用

[dcsuibian]

PUT 很少用，一般是用 PATCH ，DELETE 肯定很常用了
我挺喜欢 RESTful 的，一般能用 RESTful 的地方我都要 RESTful 。不过自己对 RESTful 的理解也是慢慢加深的，所以也不敢说接口很 RESTful
本质上来说，他这个东西省的就是沟通成本，很清晰
不用 RESTful 当然可以，但是目前没有更好或者平替的方案

[MonkeyJon]

问就是全上

[jiangzhexin]

@izneogoud 更新内容有 patch method

[ryan961]

post 一把梭。对大家都好

[nekoneko]

都用, delete 用来删除, put 用来完全更新, patch 用来部分更新

[lxh0412]

get post 就好啦，为啥要给自己找事呢

[so2back]

post 一把梭，感觉没必要讲究那么多

[EricYuan1]

@jamesxu 为啥啊

[caiqichang]

put delete 比 restful 诞生得早，restful 是给 put delete 强加概念

[Configuration]

POST /orders orders#create
GET /orders/:id orders#show
PATCH /orders/:id orders#update
PUT /orders/:id orders#update
DELETE /orders/:id orders#destroy

用啊

[nanpu]

用啊，

[ala2008]

安全检测不能使用

[pyyalt]

确实 一般很难做到 所有方法都用到，一般都是怎么方便怎么来。我司是随便用。😄

[jeesk]

看情况， 如果用 grpc 就是一把梭子。 如果用 http 只用 get /post . 方便测试开发。

[xiangyuecn]

脑子不好使 restful
脑子好使点 get post
自己说了算 post

[xiejay97]

以前分，现在全是 post ，约定 api 命名规则

[gotonull]

我们做 toB 项目的用 delete 过不了人家的安全扫描。现在全是 get 、post 一把梭

[K753255157]

我愿称之为，纯粹没事找事

[S1ahs3r]

会有 REST 警察出没的。

[arsenal4]

单一资源还好，我想问一下嵌套资源的最佳实践是什么？如获取客户的订单
1 、/customer/{customer_id}/orders：如果用这种接口写在哪个控制器里，返回结果是直接返回订单数组还是先返回客户信息，再套订单数组。如果是后者分页怎么搞？
2 、/orders?customer_id=xxx：上面的方式要查询所有客户的订单好像也没那么方便，所以用这种好像更方便

似乎看起来第一种形式更符合语义但是有不方便的地方，第二种更方便。哪一种算更符合标准 Restful 呢？

[kuaner]

不会用，很多神奇的 waf 会禁用

[xiejay97]

@arsenal4 如果是我设计，应该是 /orders/list ,customer_id 作为查询参数

[94]

全部都用 POST 也可以实现全部的业务需求。那么为什么还要多一个 GET 呢，有什么好处吗？自己回答一下就知道了。

[i8086]

经过 nn 个项目的经验，最兼容的方式全部用 POST 。

[ms17010]

会用，不过可能其他地方某些无脑一刀切的 WAF 和运维安全人员会封 PUT 、DELETE

[MoozLee]

不用，我们公司的安全检测会报“ 检测到目标服务器启用了 OPTIONS 方法”的风险提示。只能微笑.jpg 了

[Narcissu5]

现在好多人设计的 restful 接口一股 web service 的味道，完全没有意识到当年 web service 是怎么死的。。
另外一个更严重的问题是很多所谓的 restful 接口不用 http 状态码表示错误，而是把错误放在消息体里面，消息体可能还不标准，一会儿`code`一会儿`errorCode`的，结果就是完全没法做监控，系统早就挂了后端还感觉良好。

[Reficul]

说服对方，不如远离对方。 年纪大了，爱咋咋滴吧。

[chawuchiren]

以前会，现在全部 POST ，并且只有 httpcode 200

[wenkgin]

我以前的同事项目用了 get 、post ，就搁那天天 restful 接口、restful 接口，我都 webapi 就 webapi 嘛 偏要叫 restful 显得高级。
我觉得 restful 接口挺好的 规范！虽然现在很多都是通过权限去限制接口，但是没有 delete 、put 分的细且更直观。

[dd0754]

以前用，现在全部 post~~~

[HolmLoh]

用 patch 有时候前端又说用不了
用 get 做 feign 的 API 又反馈说 query parameter 超出系统限制长度，要改配置文件不愿意改，又有时候说团队规定的 LocalDateTime 格式跟 feign 自带的格式不匹配，用不了 @JsonFormat 转
反正一堆乱七八糟的问题吧，想要定义优雅的接口变成了自寻烦恼，现在已经经历了好多个项目了，不想用了，接下来全用 POST 算了

[infreboot]

restful 最傻逼的地方就是 路由上有参数，body 里也有参数。
特别是业务复杂了，路由长的一批

[HetFrame]

用 method 区分的话，全局搜一个接口结果搜出来多个，还得一个一个看 method

[GuluMashimaro]

@jamesxu 因为有的漏洞扫描软件会报这是漏洞

[nivalxer]

最早是强制要求，严格区分
后面在某些项目上某些态势感知和防火墙会识别为是异常请求直接中断，找客户联合厂家沟通又是半天
现在基本没强制要求了

[adzchao]

现在 put 都少了，如果是全量更新才会用 put ，部分更新使用的是 patch

[hyqCrystal]

不好用 就不用了

[SoloKing]

阿里云 CND 不支持 delete 和 patch ，DCDN 才支持，有时候想用也不行

[wk8023]

不用 put 和 delete ，就不是 RESTful ，就是普通的 rpc 风格

[way2create]

一般不用，没完全遵循 restful api ，直接 get post 一把梭，用地址去体现操作，不过我无所谓的，随便，只要结合应用场景有一套合理的规范即可，别跟我遇到的某些傻 x 一样把不同语言的规范直接套到别的语言或数据库甚至还自己造个框架难用的要死自我陶醉就行

[crazycloudccc]

线上 post, 调试 get;
主要是图个好记;

[JoeDH]

懒得用 我看个方法直接看 Url 就能知道他大致做什么 如果用上了还得瞟一眼 method 来区分同路径的 url 真费劲 纯粹给自己找事

[since1997]

@jamesxu indeed

[joooooker21]

下一个准备只用 POST

[QlanQ]

主要是 命名困难，所以用了 restful
但是 在查询 列表，比如 查询所有的 orders 的时候，按理说应该用 get 表示获取
但是如果有很多查询条件，又觉得 在 url 太难看，太长，而且还有可能参数数 数组或者有其他的符号，就感觉 get 不行
所以 我一般 get orders 这种，都会改成 post /order/search ，post /order 创建

[jamesxu]

@loading surge 作者现在也这么干了
https://x.com/Blankwonder/status/1922197871798960607

[sam2478]

个人觉得 put, delete 更优雅一点，Apple Ads Api 也是这样的

[skallz]

对外的接口一般就 get 和 post ，甚至只用 post ，因为 put 和 del 接口别人不一定能对接，不要给自己找麻烦，自己项目内部使用的话就随便了，反正五花八门的团队标准都见过

[ljkgpxs]

POST 一把梭哈，功能用 url 区分

[jsq2627]

刚毕业的时候会。现在见的项目多了，国内外都有，聪明和傻比的程序员也都合作过不少，最明智做法是 GET/POST 一把梭，沟通成本最低，出问题概率最低。

[yibo2018]

已经有大半年没写过这些细节了，AI 想怎么写都行

[flybluewolf]

按照楼主的说法，post 也完全可以不用，所有 get 一把梭....

[love2328]

直接 post 一把梭哈 , 特别自己的项目

[y1y1]

restful 不就是要用 method 作为语义的一部分么

[pingdog]

我大清自有国情在此，不面向锅内的业务才能用除 get post 以外的 method ，抓你做等保的时候，你在全量改 API ？黑皮只认为 get post 才是安全 method ，其它都什么牛鬼蛇神

[yuyanggongzi]

一般就用 get post delete

[AX5N]

@flybluewolf 百度还真就是这样，直接把 json 写在 url 里。

[aababc]

感觉这种帖子没啥意义，有喜欢 restful 的，有喜欢 rpc 的，有喜欢 graphql 的，最终讨论不出来个啥，自己权衡利弊之后，选择一个比较适合自己场景的，然后制定好各种规范就 OK 了

[aababc]

@QlanQ #59 好像最近出了一个规范添加了一个 Query Method 来解决这个问题

[runliuv]

@seedhk 优秀

[kakki]

这个只是风格问题,没有高下之分吧,除了那些搞什么网安的强制外,爱用什么用什么.只是各种接口管理工具五颜六色好看,那必须全用起来.

[Dogtler]

不用 put get delete post 对资源进行操作的接口能被叫做 restful 么？？？ 但是据我观察，好像还有另外的解释？

[Kumo31]

只用 PATCH ，不用 PUT 。严格来说我们用的也是不是标准的 RESTful ，是 Google Cloud 的标准： https://google.aip.dev/

[malzahar]

如果是自己的服务，那随便怎么搞都行。如果是公司的，我建议你按标准来。

虽然看起来没啥区别，但是不标准的接口对你的下游简直是灾难。

如果是标准 restful ，API 网关，metrics ，tracing 等等其他系统都可以无缝衔接，否则就要为你单独适配了，这种工作就是不做不行，做了纯属浪费时间。
作为 SRE ，我提供给别人的接口都是标准 restful ，谁给我不标准的我就喷谁

[SchwarzeR]

直接全 post ，方便规范 cover 团队能力最下限的人。
另外除了 get 和 post 的外的请求有被某些脑瘫上古运维和安全系统 ban 掉的风险 [我还见过会 ban http2.0 的

[clarkethan]

如果下游没有要求，目前倾向于 get+post 一把梭，符合中国国情

[leeg810312]

azure/aws 这些云服务的 rest api 都是这么设计的呀，我也遵循这样的规范，在公司做项目的时候就是这么用的

[niceyoo]

项目的生产环境直接把 delete 、put 请求方式禁了，只能 post 、get 一把梭

[SanjinGG]

自己写基本是怎么规范怎么来，公司项目后端用什么就用什么

[leeg810312]

我遵循 restful 规范做不同业务系统给十几个外资大企业用，它们用不同的安全扫描软件，但都没有说这个有问题。我知道政府国企限于它们的 IT 管理能力，这些机构项目可能不行，但给其他企业用说安全扫描不允许，表示非常怀疑什么安全扫描会扫出来认为这个有问题。

[akakidz]

政府类项目，只能用 post/get

[SynchronizedLock]

@EastLord 是没地方 CTRL C 吗

[fionasit007]

@jamesxu #5 之前 oss 没关 put 被网管通知过

[ychost]

@seedhk 真实，有时候 GET 都不想用了，参数嵌套了还得 POST 好使

[fuchish112]

全部 post

[Pantheoon]

跑起来就完了 整那么多事 都用 post

[jackOff]

post 一把梭

[BQsummer]

虽然我也喜欢用 restful ，但是我是做监控的，你 url 不一样，我怎么把指标聚合，纯数字还好，英文混数字的，根本没法识别

[baiyi]

怀念啊，曾经的月经贴，现在一年都看不到一个了

其实 RESTful 主要是大家有一个统一的描述接口的规范，比如接口的安全性，幂等性，用不用取决于涉及到的团队开发人员以及项目使用的相关 web 组件

[spike0100]

get+post 。其他的用的少

[EastLord]

@SynchronizedLock 为了与项目代码风格保持一致

[Ketteiron]

全用 post 。
现实是复杂的，RESTful 的表达能力不足以覆盖所有 case ，强行使用统一约定会让一些简单的东西变得难以理解。
2#说 `全用 POST ，那么安全审核无法直接区分这个 POST 是“新增”还是“删除”，只能靠解析 URL 或 Body ，这样更复杂印象性能且容易漏。`
为什么要区分是新增还是删除，而且一个接口本来就可以删除一些 A ，新增一些 B ，修改一些 C 。
真正的安全策略应该基于权限规则和业务逻辑，不应该简单地基于约定式的 Method ，它本质上和 /add /edit /del /info /page 一模一样，能严格遵守 RESTful 标准的人，同样能遵守自定义的语义要求。
我一直觉得接口的语义化完全没必要，一个硬编码玩出花来有什么意义，只要把代码给组织好就足够了。

[Oktfolio]

很少有全量更新的场景，所以不怎么用 PUT 。用 PATCH + Json Patch ，不然就是 POST /resources/{id}:action 这种设计。

[kinkin666]

后端服务，post 一把梭哈，而且有时候还有超接口，里面就俩字段 method 和 payload ，可扩展性 max

[nexo]

你这题目就是个悖论 如果你遵循 restful 风格就得用 put 而且你问出这个问题就说明了你不懂 restful

[illiteracy0001]

标准是标准，真用起来就会发现各种问题，完全的资源抽象有一定的难度、前端也不一定愿意配合