HTTP 1.1新增PUT、DELETE等方法是否为支持REST？求原始添加原因参考

我们现在常把PUT、DELETE和REST绑定，但其实这俩方法在1997年的HTTP/1.1里就有了，比2000年的REST论文早3年。它们被加入的核心原因，是为了补全HTTP作为分布式超媒体协议的资源操作能力，解决HTTP/1.0的语义模糊问题：

• 解决POST语义过载的问题：HTTP/1.0里除了GET，几乎所有非读取操作都靠POST包办——创建资源、更新内容、删除数据全用POST，服务器得靠解析请求体或额外参数才能判断客户端意图，很容易出现歧义。PUT和DELETE把这些操作的语义明确下来：PUT是替换或创建指定URI的资源，DELETE是删除指定URI的资源，双方不用额外猜意图。
• 强化无状态协议的完整性：HTTP的核心设计是无状态，每个请求要自带足够信息。PUT和DELETE的语义本身就说明了操作目的，不用依赖会话状态来辅助判断，让分布式环境下的服务交互更可靠。
• 优化缓存与代理的处理逻辑：HTTP/1.1很看重缓存和代理的效率，模糊的POST语义让缓存服务器很难判断要不要失效资源。而PUT操作明确是修改指定URI的资源，缓存可以直接标记对应资源失效；DELETE操作后，缓存里的对应资源也能直接清理，代理能更自动化地处理这些场景。
• 完善分布式资源的CRUD能力：HTTP最初就是为分布式超媒体系统设计的，需要一套完整的资源增删改查能力。HTTP/1.0只有GET（查）和POST（杂项操作），PUT补上了“指定位置创建/更新”，DELETE补上了“删除”，让协议能更好地支持分布式环境下的资源管理。

不涉及REST的参考资料 #

• RFC 2068（HTTP/1.1原始规范）：1997年发布的官方标准，详细定义了PUT、DELETE的功能和设计动机，完全不涉及REST概念，是最权威的原始参考。
• HTTP工作组1996-1997年讨论邮件：早期HTTP工作组在制定1.1版本时的内部讨论记录，里面明确提到添加这些方法是为了解决POST语义模糊、完善资源操作体系，所有讨论都早于REST理论的提出。

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