为何HTTP协议除GET、POST外还需PUT、PATCH、DELETE等请求方法？

你说的结论从纯功能实现层面完全成立：PUT、PATCH、DELETE等方法能实现的所有操作，确实都可以通过GET、POST模拟完成，早期不少Web项目甚至全站业务都只靠这两个方法跑通，不存在技术上的实现障碍。但HTTP协议从设计之初就不是只服务于单点业务逻辑的私有工具，它是整个Web生态通用的通信标准，其他请求方法存在的核心价值，本质是用统一约定降低全链路的协作成本，主要体现在三个方面：

• 统一语义减少额外沟通成本
  如果所有写操作都塞到POST里，每个团队都要自定义规则标记操作类型：有人在URL后缀加?action=delete，有人在请求体里藏_method=put字段，还有人直接在路径里写/delete_article这类动词。不同服务的规则没有统一标准，对接接口时要逐篇翻自定义文档才能搞懂请求意图，很容易出误解和bug。而用标准方法时，看到DELETE就知道是删除资源、PATCH是部分更新、PUT是全量替换，不需要额外解析自定义参数，所有开发者、所有框架对方法的认知是完全对齐的。
• 适配链路通用组件的默认规则
  一次HTTP请求从发起到响应，中间会经过浏览器、CDN、缓存代理、防火墙、网关等大量通用组件，这些组件都是按照HTTP标准写死了默认处理逻辑：
  • GET、HEAD属于安全方法，定义是无论请求多少次都不会改变服务端资源状态，默认会被缓存组件缓存结果；如果把删除、修改操作做在GET上，很可能被爬虫、预加载逻辑误触发，直接把线上数据搞乱。
  • PUT、DELETE、GET属于幂等方法，定义是同一个请求执行一次和执行多次的效果完全相同；如果请求遇到网络超时，代理、SDK可以放心自动重试，不会产生重复创建数据这类副作用。而POST默认是非幂等的，链路组件不会随便自动重试。如果把所有删改操作都塞到POST里，这些通用组件的默认能力直接失效，缓存、重试、防重复提交的逻辑全要自己在业务层重写，长期来看反而复杂度更高。
• 降低接口设计和维护成本
  现在主流的接口建模思路都是面向资源设计，比如/articles/456就代表ID为456的文章资源，配合不同请求方法直接对应资源操作：GET查询、PUT全量更新、PATCH部分更新、DELETE删除，路径里不需要加冗余的动词，结构非常清晰。做权限控制的时候，网关层甚至不用解析请求体和URL参数，直接根据请求方法+资源路径就能做统一的权限拦截，比如普通访客只放行GET，内容编辑放行GET/PUT/PATCH，管理员才开放DELETE权限，规则透明且易维护。

当然你完全可以在自己的项目里只用GET、POST实现所有功能，就像用螺丝刀也能把钉子敲进木板，但既然有标准化的专用工具，刻意弃用的话只会在跨团队协作、链路适配、长期维护的时候付出额外成本，所谓“只用两种方法更简单”只是写少量业务代码时的短期错觉，放到整个Web生态的协作场景里反而更麻烦。

内容的提问来源于stack exchange，提问作者Samisai