为什么很多大厂 API 不再使用 PUT 和 DELETE？

沉默是金总会发光大家好我是沉默在大多数RESTful API 教程中我们都会看到一套经典映射关系方法含义GET获取资源POST创建资源PUT更新资源DELETE删除资源这种设计看起来清晰、优雅、符合规范。但如果你观察很多大型互联网公司的 API 设计会发现一个有意思的现象很多核心接口很少直接使用 PUT 和 DELETE反而更常使用POST 或 PATCH来完成更新、删除等操作。这就让人产生疑问既然 RESTful 推荐使用 PUT 和 DELETE为什么在真实的大型系统中却越来越少见实际上当系统进入高并发、分布式、复杂业务场景时API 设计往往需要在规范、灵活性、安全性和工程实践之间做权衡。接下来我们就一起看看PUT 和 DELETE 在工程实践中为什么逐渐被“弱化”以及大厂通常是如何设计 API 的。-01-PUT 与 DELETE 的设计初衷HTTP 在设计之初其实非常优雅。RESTful 架构把HTTP 方法和资源操作做了严格映射方法含义GET获取资源POST创建资源PUT完整更新资源PATCH部分更新资源DELETE删除资源例如更新用户信息PUT /users/12345{name: Alice,email: aliceexample.com,age: 30}PUT 的语义非常明确用新的资源完全替换旧资源如果缺字段就会被删除。删除资源DELETE /users/12345服务器返回204 No Content表示资源已经被删除。在纯 REST 理念下PUT 更新资源DELETE 删除资源非常干净。但是真实世界的系统很少这么简单。-02-为什么现实系统很少使用 PUT 和 DELETE很多开发者会发现在公司系统里常见的是POST /order/cancelPOST /user/updatePOST /order/delete而不是PUT /orders/{id}DELETE /orders/{id}这背后其实有四个原因。原因一真实业务不是“资源操作”REST 的假设是所有业务都可以抽象成资源。但现实是很多业务是行为Action。例如电商取消订单取消订单背后涉及修改订单状态恢复库存退款发送消息写审计日志这已经不是DELETE /order这么简单。所以很多公司设计成POST /orders/{id}/cancel因为这是一个动作不是删除资源。原因二软删除是常态很多业务系统几乎不会真正删除数据。原因很简单需要审计数据恢复对账风控所以数据库通常会设计is_deleteddeleted_at删除订单其实是UPDATE order SET deleted 1所以 API 更像POST /orders/{id}/delete而不是DELETE /orders/{id}原因三复杂业务需要批量操作REST 的 DELETE 设计是DELETE /users/123但企业系统经常需要批量删除例如删除1000个用户这时接口通常设计为POST /users/batch-delete请求体{userIds: [1,2,3,4]}DELETE 在这种场景就不太合适。原因四很多网关和客户端限制历史上很多系统浏览器表单API 网关负载均衡对 HTTP 方法支持并不好。例如HTML form 只支持GETPOST很多早期系统为了兼容性全部使用 POST。这个习惯延续到了今天。PUT 的另一个问题 —— 全量更新PUT 的设计要求客户端提交完整资源例如PUT /users/123如果只想修改邮箱{email: newemail.com}但原数据是{name: Alice,email: oldemail.com,age: 30}PUT 会导致name 丢失age 丢失因此现代 API 更常用PATCH例如PATCH /users/123{email: newemail.com}只更新字段。-03-真正的大厂 API 其实是这样设计的很多成熟系统会采用混合策略标准资源操作使用 RESTGET /users/{id}PUT /users/{id}DELETE /users/{id}业务行为使用 POSTPOST /orders/{id}/cancelPOST /orders/{id}/refundPOST /orders/{id}/confirm批量操作POST /orders/batch-cancelPOST /users/batch-delete部分更新PATCH /users/{id}换句话说REST 是基础但不是枷锁。工程实践通常是REST Action API 混合设计-04-总结PUT 和 DELETE 并没有被淘汰。但在现代系统中很多业务并不是资源操作而是业务行为。所以越来越多 API 设计变成POST Action例如POST /orders/{id}/cancelPOST /orders/{id}/refund而不是DELETE /orders/{id}真正成熟的 API 设计不是死守 REST而是让接口既清晰又符合业务语义。热门文章一套能保命的高并发实战指南架构师必备用 AI 快速生成架构图-05-粉丝福利我这里创建一个程序员成长副业交流群和一群志同道合的小伙伴一起聚焦自身发展可以聊技术成长与职业规划分享路线图、面试经验和效率工具探讨多种副业变现路径从写作课程到私活接单主题活动、打卡挑战和项目组队让志同道合的伙伴互帮互助、共同进步。如果你对这个特别的群感兴趣的可以加一下微信通过后会拉你入群但是任何人在群里打任何广告都会被我T掉。