为何大公司纷纷减少对PUT和DELETE请求的依赖，转向其他HTTP方法？

PUT和DELETE被视为修改和删除资源的标准方法。只是当我们放眼望去那些日活过亿的互联网巨头时却发现他们正在悄然抛弃这些"教科书式"的方法。取而代之的是以POST和PATCH为主导的API设计模式。这一现象并非偶然而是平安、可靠性、运维成本等多重因素综合作用的后来啊，拯救一下。。

一、平安性：防火墙与WAF的无声拦截

"你以为你发出了DELETE请求？可能连服务器都没收到"——某资深网关工程师的调侃

让我们先看一个真实案例：某大型电商平台曾因开发人员误将/order/{id}接口暴露给前端直接使用DELETE,导致黑客通过跨站请求伪造攻击批量删除订单数据。事故发生后团队马上进行了两项关键改进：

• 所有写操作统一由POST承载：

  POST /api/v1/order/delete
  Content-Type: application/json
  {
    "id": 12345,
    "reason": "user_request",
    "confirmation_token": "aBcDeF123"
  }

• 网关层完全屏蔽非GET/POST请求：
  • - IaaS防火墙默认拒绝PUT/DELETE流量;
  • - WAF规则增加对异常HTTP方法的监控;
  • - API网关统一转换内部协议.

为什么浏览器成为平安漏洞？

"我们发现约70%的PUT/DELETE请求其实吧是来自于未经授权的浏览器环境。" ——某云服务商平安团队报告节选 AJAX跨域预检机制: 浏览器会自动对PUT/DELETE发起OPTIONS预检请求， 增加了50%+延迟. CSRF攻击面积: PUT/DELETE通常不携带CSRF token保护. 缓存污染风险: 某些代理服务器可能错误缓存非GET请求. 二、 操作一波。 幂等性理论 vs 分布式现实：哪个更重要？

翻旧账。 "按道理讲幂等是美好的，但当你遇到半提交事务时..." ——某分布式系统专家 警告：以下内容包含高并发场景下HTTP方法选择可能引发的数据一致性问题。