为什么PUT和DELETE请求在大公司中逐渐被弃用一、引言RESTful 的 “标准款”为何大厂不买单1.1 PUT 与 DELETE 的设计初心RESTful 的理想模型在 HTTP 协议的大家族里PUT 和 DELETE 请求方法就像一对怀揣着明确使命的 “使者”它们在 RESTful 架构中扮演着极为关键的角色。RESTful 架构这个追求简洁、优雅与规范的设计理念将 HTTP 方法与资源操作进行了堪称完美的映射。PUT从语义上讲它的使命是对资源进行全量替换更新。想象一下你有一个用户信息的资源存储在/users/{userId}这样的路径下。当你想要更新用户信息时使用 PUT 请求就好比为这个用户换上一套全新的 “装备”。比如PUT /users/12345 HTTP/1.1 Content-Type: application/json { name: Alice, email: aliceexample.com, age: 30 }在这个例子中PUT 请求会带着请求体中的数据风风火火地来到服务器将/users/12345这个资源原有的一切都替换成请求里提供的新数据。如果原数据里有些字段在这次请求中缺失了那就会被毫不留情地删除就像大扫除时把不需要的东西都清理出去一样。DELETE 的职责则更加干脆利落它就是专门用来删除资源的。同样以用户信息为例假设你要删除 ID 为 12345 的用户资源只需要发送这样一个 DELETE 请求DELETE /users/12345 HTTP/1.1一旦服务器收到这个请求并成功执行通常会返回一个204 No Content的状态码仿佛在告诉你“放心吧这个资源已经被我成功删除啦啥都没留下。” 就像是把一件物品从仓库里彻底移除不留一丝痕迹。在理想的 RESTful 世界里PUT 和 DELETE 的操作简单直接、干净利落一切都按照既定的规则有条不紊地进行着资源的更新和删除就应该是这么纯粹、这么理想化。然而现实却总是充满了变数当我们把目光投向大型互联网公司复杂的业务场景时却发现一个令人困惑的现象PUT 和 DELETE 这两位在理论上备受推崇的 “标准款” 请求方法在实际的核心接口设计中却很少露面仿佛被大厂们悄悄地 “打入了冷宫”。这背后究竟隐藏着怎样的秘密呢是什么原因让大厂们对它们敬而远之接下来就让我们一起深入探寻其中的缘由 。二、真相揭秘PUT/DELETE 在大厂 “水土不服” 的五大原因2.1 原因 1真实业务是 “行为”而非单纯 “资源操作”RESTful 架构的核心假设是世间万物的业务都能被巧妙地抽象成一个个资源就像把生活中的各种物品分类放进不同的盒子里每个盒子都有对应的标签资源路径而 PUT 和 DELETE 就像是打开盒子进行更新或直接扔掉盒子的操作工具 。但在大厂那复杂如迷宫的业务世界里很多高频业务场景更像是一连串紧密关联的 “行为”而非简单的资源操作。以电商行业中常见的订单取消场景为例当用户点击 “取消订单” 按钮时背后触发的可不只是简单地删除订单这个资源。首先订单的状态得从 “已下单” 修改为 “已取消”就好比给订单这个 “小卡片” 换了个标注接着之前为该订单预留的库存得赶紧恢复不然仓库的库存数据就乱套了然后支付系统得启动退款流程把钱退还给用户这可是关乎用户钱包的大事与此同时消息系统要发送通知给用户告知订单取消的结果让用户心里有数最后还得在审计日志里详细记录下这次取消操作的相关信息以便后续追溯和分析。这么一套环环相扣的流程下来显然不是简单地发送一个 DELETE /orders/{orderId} 请求就能解决的。如果硬要用 DELETE 请求那服务器收到请求后只能干删除订单这一件事其他的后续操作就都被无情地忽略了整个业务流程就会像断了线的珠子散落一地。所以大厂们更倾向于设计像 POST /orders/{orderId}/cancel 这样的行为化接口把取消订单这个行为当成一个整体来处理每个步骤都能精准地在接口逻辑里实现这样就能完美地匹配复杂业务的语义让业务流程顺畅地跑起来 。2.2 原因 2软删除成常态DELETE 语义完全不匹配在大厂的数据管理世界里数据就像是珍贵的宝藏每一条都蕴含着巨大的价值所以很少会被真正地彻底删除。为了满足审计、数据恢复、对账风控等多方面的需求软删除方案成了大厂们的心头好。所谓软删除简单来说就是不直接把数据从数据库里抹除而是通过一个特殊的字段比如 “is_deleted”是否已删除或者 “deleted_at”删除时间来标记数据的状态。想象一下数据库就像一个大仓库数据是里面的货物。软删除就好比给要 “删除” 的货物贴上一个 “已下架” 的标签把它放到仓库的一个特殊角落但货物还在仓库里存着。以订单数据为例当要 “删除” 一个订单时实际执行的 SQL 语句可能是这样的UPDATEorderSETis_deleted1,deleted_atNOW()WHEREorder_id12345;这条语句把订单的 “is_deleted” 字段设置为 1表示已删除同时记录下删除时间。这样一来在需要审计数据时能通过这个字段快速筛选出所有被 “删除” 的订单查看当时的业务情况要是哪天突然发现误删了订单还能根据这些标记把订单数据恢复回来在进行对账和风控分析时这些被软删除的数据也能提供重要的参考依据。然而DELETE 请求的语义却是 “彻底移除资源”就像直接把仓库里的货物扔出去再也找不回来了。这与软删除的逻辑完全相悖就像两个背道而驰的人怎么也走不到一起。所以在大厂的 API 设计中更常见的是 POST /orders/{id}/delete 这样的接口在接口内部执行软删除的逻辑而不是使用 DELETE 请求来实现真正的物理删除。2.3 原因 3批量操作需求PUT/DELETE 难以支撑在理想的 RESTful 设计中PUT 和 DELETE 请求主要是针对单个资源进行操作的就像一次只处理一件事情专注又简单。比如 DELETE /users/123这个请求就是专门用来删除 ID 为 123 的单个用户资源的清晰明了。但在大厂实际的开发场景中就像一个繁忙的大工厂经常会遇到需要批量处理的任务。想象一下一家大型互联网公司要对用户数据进行清理需要一次性删除 1000 个长期未活跃的用户。如果按照 RESTful 中 DELETE 的设计那就得发送 1000 次 DELETE 请求每次请求删除一个用户这就好比让工人一个一个地搬运 1000 块砖效率极其低下不仅会给服务器带来巨大的压力网络带宽也会被大量占用就像一条小水管要同时供应大量的水肯定会不堪重负。而且DELETE 请求在设计上还有个限制它无法在请求体中传递多个资源 ID。这就像是一个只能装一件东西的小袋子你却想让它装下很多东西根本装不下。所以大厂们在面对这种批量操作需求时往往会另辟蹊径设计像 POST /users/batch-delete 这样专门的批量操作接口。在这个接口的请求体中可以轻松地携带一个用户 ID 列表比如{userIds:[1,2,3,4,...,1000]}服务器收到这个请求后就可以根据这个列表一次性高效地处理这 1000 个用户的删除操作就像用一辆大卡车一次性把 1000 块砖都运走大大提高了工作效率完美地满足了实际业务开发中的批量操作需求 。2.4 原因 4网关与客户端限制兼容性优先于规范在互联网发展的漫长历史长河中早期的浏览器表单、老旧的 API 网关以及负载均衡设备就像一些 “老古董”对 HTTP 方法的支持并不全面它们大多只认识 GET 和 POST 这两种请求方法就像一个人只熟悉两种语言其他语言一概听不懂。比如 HTML 表单作为网页中常用的数据提交方式在过去很长一段时间里它只支持 GET 和 POST 请求。这就导致很多早期的系统为了能够在不同的客户端和网关环境中顺利运行实现多端系统的兼容性统一采用了 POST 接口来处理各种业务逻辑。就像为了让所有人都能听懂大家都统一说一种大家都熟悉的语言。这种开发习惯就像一个无形的传统一直延续到了今天。即使后来 HTTP 协议不断发展出现了 PUT 和 DELETE 等更多强大的请求方法但由于历史遗留问题和对现有系统兼容性的考虑大厂们在新的项目开发中也很难轻易地改变这种使用 POST 接口的习惯。同时部分网关出于安全考虑对 PUT 和 DELETE 设置了严格的拦截策略。想象一下网关就像一个严格的门卫PUT 请求如果被恶意利用比如用来上传木马文件等恶意程序就像有人试图把危险物品带进大门会对系统安全造成严重威胁。DELETE 请求也存在类似的风险如果被不法分子利用可能会导致大量重要数据被误删或恶意删除。所以为了防止这些恶意攻击网关这个 “门卫” 不得不对 PUT 和 DELETE 请求进行严格的审查和拦截这也在一定程度上降低了这两种请求方法在实际开发中的使用率 。2.5 额外痛点PUT 的 “全量更新” 陷阱PUT 请求在设计上有一个比较 “苛刻” 的要求那就是客户端在发送 PUT 请求时必须提交完整的资源数据。这就好比你要给一个房间重新布置PUT 的要求是你得把房间里所有的东西都搬走然后按照新的布局重新摆放所有的东西哪怕你只是想换一盏灯。举个具体的例子假设我们有一个用户资源存储在/users/123路径下原数据如下{name:Bob,email:bobexample.com,age:25,phone:123-456-7890}现在我们只是想更新用户的邮箱地址按照 PUT 的设计我们需要发送这样一个请求PUT /users/123 HTTP/1.1 Content-Type: application/json { name: Bob, email: newemailexample.com, age: 25, phone: 123-456-7890 }在这个请求中我们不得不把所有已知的用户信息都重新发送一遍仅仅是为了更新一个邮箱字段。如果在实际开发中客户端不小心遗漏了某些字段比如忘记发送 “phone” 字段那么服务器在处理这个 PUT 请求时就会把原数据中的 “phone” 字段清空就像房间里的某个物品被莫名其妙地扔掉了这就会导致数据丢失的风险给业务带来严重的影响。相比之下PATCH 请求就显得更加灵活和人性化。PATCH 支持部分更新它就像一个可以只替换房间里某一件物品的工具只需要客户端传递待修改的字段即可。比如使用 PATCH 请求更新用户邮箱地址只需要这样发送PATCH /users/123 HTTP/1.1 Content-Type: application/json { email: newemailexample.com }这样服务器只会对请求中传递的 “email” 字段进行更新其他字段则保持不变完美地避免了因部分字段遗漏而导致的数据丢失问题。所以在实际开发中PATCH 逐渐替代 PUT 成为更新资源的优选方法越来越受到开发者们的青睐 。三、大厂解法API 设计的 “混合策略”不被规范绑架3.1 REST Action API分场景适配才是王道面对 PUT 和 DELETE 在实际应用中出现的种种问题大厂们并没有选择彻底抛弃 RESTful 架构而是另辟蹊径采用了一种更加灵活的 “混合策略”。这种策略就像是为不同的业务场景量身定制了合适的 “衣服”让 API 的设计既保留了 RESTful 的规范性又具备了应对复杂业务的灵活性。在大厂的 API 设计蓝图里对于那些简单且标准的资源操作比如获取用户信息、查询商品详情等依然坚定地遵循 RESTful 规范使用 GET、PUT、DELETE 等标准的 HTTP 方法。以获取用户信息为例使用 GET 请求清晰明了GET /users/12345 HTTP/1.1这样的设计不仅符合开发者对于 RESTful 架构的认知习惯而且在接口的维护和理解上也更加容易就像按照标准的地图导航很容易就能找到目的地。然而当遇到复杂的业务行为时大厂们则会果断地打破常规采用 POST 行为路径的设计模式。比如在电商业务中订单退款这个复杂的业务场景涉及到与支付系统、库存系统、物流系统等多个系统的交互还需要处理各种异常情况。如果使用传统的 RESTful 设计很难用一个简单的 HTTP 方法来准确地描述这个行为。所以大厂们会设计这样的接口POST /orders/12345/refund HTTP/1.1 Content-Type: application/json { reason: 商品质量问题, refundAmount: 100.00 }在这个接口中通过 POST 方法表明这是一个执行特定行为退款的请求而/orders/12345/refund这个路径则清晰地描述了行为的具体内容请求体中包含了退款的原因和金额等必要参数。这种设计方式就像是给复杂的业务行为贴上了一个明确的标签让开发者能够一目了然地知道这个接口的作用和使用方法同时也能更好地满足业务的复杂逻辑需求 。3.2 批量操作专属接口POST 承接高频需求为了解决 PUT 和 DELETE 在批量操作方面的不足大厂们专门为批量操作设计了特定的接口。这些接口就像是专门为批量任务打造的 “超级工具”能够高效地处理各种批量需求。比如在电商平台的商品管理系统中经常会遇到需要批量下架一批商品的情况。这时大厂们会设计一个类似这样的接口POST /products/batch-offline HTTP/1.1 Content-Type: application/json { productIds: [1001, 1002, 1003, 1004, 1005] }通过这个 POST 请求将需要下架的商品 ID 列表放在请求体中发送给服务器。服务器收到请求后就可以根据这个列表一次性对这些商品执行下架操作大大提高了操作效率避免了使用 DELETE 请求时需要多次发送请求的繁琐过程 。再比如在用户管理系统中如果要对一批用户进行批量审核也可以设计一个类似的接口POST /users/batch-audit HTTP/1.1 Content-Type: application/json { userIds: [2001, 2002, 2003], auditResult: 通过, auditComment: 用户资料审核通过 }这样的批量操作接口不仅解决了 PUT 和 DELETE 无法处理多资源的痛点而且在接口文档的归类和管理上也更加方便开发者可以很容易地在文档中找到与批量操作相关的接口提高了开发和维护的效率 。3.3 PATCH 精准补位替代 PUT 的部分更新方案在需要对资源进行部分更新的场景下PATCH 请求就像是一个精准的 “修补匠”完美地替代了 PUT 请求成为了大厂们的首选方案。PATCH 请求的最大优势在于它只需要客户端传递待修改的字段而不需要像 PUT 请求那样提交完整的资源数据。这就好比给一件有小破损的衣服进行修补只需要针对破损的部分进行处理而不需要把整个衣服都重新制作一遍。例如在一个用户信息管理系统中如果只需要更新用户的手机号码使用 PATCH 请求就可以这样发送PATCH /users/12345 HTTP/1.1 Content-Type: application/json { phone: 13800138000 }服务器收到这个 PATCH 请求后只会对用户信息中的 “phone” 字段进行更新其他字段则保持不变。这样不仅减少了网络传输的数据量提高了传输效率还避免了因为部分字段遗漏而导致的数据丢失风险让数据的更新更加安全可靠 。随着互联网业务的不断发展和变化PATCH 请求在现代 API 设计中的地位越来越重要它已经成为了实现部分更新的主流选择被广泛应用于各种项目开发中 。四、误区澄清PUT/DELETE 并未 “淘汰”只是 “按需使用”4.1 PUT/DELETE 的适用场景尽管 PUT 和 DELETE 请求在大厂的核心业务接口中确实不如 POST 和 PATCH 那么常见但这并不意味着它们已经被彻底弃用就像一把宝刀虽然在某些战斗中不太适用但在特定的场景下依然能发挥出巨大的威力 。在一些特定的业务场景和技术环境中PUT 和 DELETE 仍然有着不可替代的价值。在测试环境和开发阶段PUT 和 DELETE 请求就像是两个得力的 “小助手”能够帮助开发人员快速地对测试数据进行清理和初始化。比如在进行接口测试时开发人员可能需要频繁地创建、更新和删除测试数据以验证接口的各种功能是否正常。这时使用 PUT 和 DELETE 请求就可以轻松地实现这些操作而且由于测试环境的数据本身就不涉及真实的业务数据所以不用担心数据丢失或安全问题。例如在一个电商系统的测试环境中开发人员可以使用 DELETE 请求来删除一些过期的测试订单为新的测试用例腾出空间就像清理仓库里过期的货物一样。在一些基础信息的更新场景中PUT 请求也能发挥出它的优势。当需要对资源进行全量更新并且客户端能够准确地获取到完整的资源数据时PUT 请求就可以派上用场。比如在用户管理系统中如果用户需要重置自己的所有资料包括用户名、密码、邮箱、手机号等这时使用 PUT 请求就可以一次性将所有新的资料提交给服务器服务器直接用新数据替换旧数据操作简单直接就像给用户换上一套全新的 “装备”。DELETE 请求在处理一些真正需要物理删除资源的场景时依然是最佳选择。比如在文件管理系统中如果某个文件已经不再需要并且没有任何备份或后续用途那么使用 DELETE 请求就可以直接将文件从服务器上删除释放存储空间就像把不需要的物品从仓库里彻底扔掉一样。五、总结API 设计的终极原则 —— 业务优先规范为辅经过一番深入的探讨我们已经清晰地了解到 PUT 和 DELETE 请求在大型互联网公司的 API 设计中逐渐被冷落的背后原因。这并非是因为它们本身存在技术缺陷而是在面对高并发、分布式的复杂业务场景时大厂们从灵活性、安全性和工程实践等多方面进行综合权衡后做出的选择 。在真实的业务世界里行为化的操作远比单纯的资源增删改查要复杂得多这就使得 POST 行为路径的接口设计模式更能精准地匹配业务语义让 API 的设计与业务需求无缝对接。同时软删除策略的广泛应用、批量操作的高频需求、网关与客户端的兼容性限制以及 PUT 全量更新的潜在风险都像是一道道现实的 “关卡”让 PUT 和 DELETE 在实际应用中面临重重困难 。不过这并不意味着 PUT 和 DELETE 已经被彻底淘汰在一些特定的场景下它们依然有着独特的价值就像在测试环境、特定的资源更新和物理删除场景中它们仍然能发挥出不可替代的作用 。从大厂的 API 设计实践中我们可以深刻地领悟到优秀的 API 设计并不是一味地死守 RESTful 的教条而是要在规范与实际业务之间找到一个完美的平衡点。让接口既具备清晰易懂的语义又能准确无误地匹配业务需求这才是 API 设计的精髓所在 。RESTful 架构为我们提供了一个坚实的基础和规范是我们在 API 设计之路上的重要工具但它绝不是束缚我们思维和创新的枷锁。在实际的开发过程中我们应该以开放的心态根据具体的业务场景和需求灵活地选择和运用各种设计模式和方法打造出更加高效、灵活、易用的 API 。