大厂为何弃用PUT/DELETE？RESTful实践中的取舍

1. 为什么大厂逐渐弃用 PUT、DELETE 请求？

作为一名经历过多次技术架构升级的后端工程师，我亲眼见证了从严格遵循 RESTful 规范到逐步简化 HTTP 方法使用的转变过程。最初，我们团队也坚持使用 PUT 和 DELETE 方法，认为这是最"正统"的做法。但在实际生产环境中，这种坚持给我们带来了无数意想不到的麻烦。

记得有一次线上故障，我们的 DELETE 请求被某台老旧防火墙设备拦截，导致整个删除功能失效。排查这个问题花了团队整整两天时间，最终发现是中间设备对非标准 HTTP 方法的支持不完整。这次经历让我们开始重新思考：在工程实践中，理论上的"正确"和实际上的"可行"到底哪个更重要？

2. 核心原因深度解析

2.1 基础设施兼容性问题

现代互联网架构中，请求从客户端到服务端要经过重重关卡：

1. 客户端层：浏览器、移动端APP、小程序等
2. CDN边缘节点：负责缓存和加速
3. WAF防火墙：防护SQL注入等攻击
4. API网关：路由和鉴权
5. 负载均衡：流量分发
6. 服务网格：服务间通信

在这个过程中，每个环节都可能对非标准HTTP方法（PUT/DELETE）处理不一致。我们曾遇到过：

• 某CDN厂商的缓存策略对PUT请求不生效
• 某WAF默认配置会拦截所有DELETE方法
• 某些企业内网代理服务器会改写非GET/POST请求

实际案例：某电商平台在618大促期间，发现部分地区的用户无法完成订单更新操作。最终定位是某地运营商设备对PUT请求做了特殊处理，导致请求体丢失。改用POST后问题立即解决。

2.2 跨域请求的性能损耗

浏览器对跨域请求有严格的安全限制。根据CORS规范：

• 简单请求（GET/POST/HEAD + 简单Content-Type）可以直接发送
• 非简单请求（如PUT/DELETE）必须先发送OPTIONS预检请求

这种机制带来的问题包括：

1. 延迟翻倍：每个PUT/DELETE请求实际产生2次网络往返
2. 网关压力：OPTIONS请求同样消耗网关资源
3. 移动端问题：在弱网环境下，预检失败率显著升高

我们做过实测对比：

| 请求类型 | 平均延迟(ms) | 失败率