从我understand 来看，PUT 请求发送整个对象，而 PATCH 请求只发送 diff，用于更新数据库中的对象。
为什么要对 PATCH 执行 PUT？ PATCH 似乎很多轻了。我没有看到 PUT 有任何好处（我确信它们存在，我只是不知道它们是什么）。
【问题讨论】：
标签： http http-method
更好的看待方式是 PUT 替换资源，而 PATCH 用于提供指令以更改资源。
替换资源始终是一种安全且幂等的操作，因为它不依赖于资源的现有状态。同时，更改资源的请求可能取决于该资源的状态，因此可能会产生其他影响。
HTTP PATCH 动词在RFC 5789 中定义，其中声明：
PUT 和 PATCH 请求之间的区别体现在 服务器处理封闭实体以修改资源的方式 由 Request-URI 标识。在 PUT 请求中，包含的实体 被认为是存储在 源服务器，客户端请求存储的版本 被替换。然而，对于 PATCH，封闭的实体包含一个集合 描述资源当前如何驻留在 应修改原始服务器以生成新版本。补丁 方法影响由 Request-URI 标识的资源，并且它 也可能对其他资源产生副作用；即新资源 可以通过应用程序创建或修改现有的 补丁。
接着说：
PATCH 既不安全也不幂等
【讨论】：
您可能想要创建资源，或者可能没有可用的适用 PATCH 格式（想想二进制文件）。
【讨论】：
是否还需要在 API 中提供 PUT 端点？
Maybe I don't want to take the diff and deduce where I should save it so that everything makes sense. Maybe I just want to work with full resources instead of messing around with little parts of them. >> 你也可以使用 PATCH 进行完整更新，不是吗？
【讨论】：
相当一部分HTTP标准已经过时，所以PATCH可以完全替代PUT也就不足为奇了。
在 RESTful API 中，人们常常将 PUT 误认为是“更新整个资源”，但实际上 PUT 的语义是“替换资源”。不幸的是，HTTP 中有一个可悲的设计：PUT 被定义为在新资源不存在时创建它们，因此 PUT 有时被用作 POST 的幂等替代方案。
PATCH在一定程度上是对PUT的模仿，因此也包含了POST的部分职责。但是，如果你只想有一个“修改现有资源”的动作，你只需要使用PATCH（PATCH不是幂等的，HTTP的另一个可悲的设计）。
深入研究 REST 和 HTTP 标准方法的人最终会发现，一个简单的 RPC 接口可以更好地实现你需要的所有动作。
【讨论】：