我正在努力学习PUT和PATCH之间的区别。如果我需要创建一个更新资源的路由，例如User，我应该同时实现PUT和PATCH吗？
如果我可以使用PATCH部分更新资源，为什么要使用PUT？
我正在努力学习PUT和PATCH之间的区别。
从"；它们怎么一样">
PUT和PATCH都在远程创作上下文中使用；我们使用这些消息语义来告诉服务器使其自己对某些资源的表示看起来像我们的本地副本。
例如，如果我想更改我网站主页的标题，我可以
GET /home.html
将当前版本加载到我的HTML编辑器中。然后我可以对本地副本进行更改。为了释放我的更改，我向服务器发送消息"；把你的复制品做成我的复制品"；。
使用PUT，请求的有效负载是我的文档版本的完整副本。我将整个文档发回服务器进行处理。
使用PATCH，我创建了一个"；补丁文档"；，也就是说，使用服务器所理解的某种媒体类型来表示我的更改。服务器应该通过将补丁文档应用于其本地副本来为自己计算新的表示形式。
PUT具有幂等语义；这意味着，像web浏览器和反向代理这样的通用组件知道，连续接收到的同一请求的多个副本与该请求的单个副本意味着相同的事情。这意味着，如果出现网络故障，请求或响应可能已丢失，我们可以自动重新发送请求。
PATCH不承诺幂等处理——即使补丁文档描述了对资源的幂等更改，通用组件也不会知道重新发送请求是安全的。
另一方面，如果您的文档较大(相对于HTTP标头的大小(，而您的更改较小，则补丁文档将小于完整表示；如果网络足够可靠，那么较小的请求比可重复的请求具有更好的投资几率。
当然，您最灵活的做法是同时支持这两种方法，并在响应OPTIONS请求时描述您支持的补丁格式的媒体类型。这允许客户端根据自己的本地上下文选择适当的方法。
PATCH比PUT需要更多的兼容性，因为客户端和服务器都需要了解相同的补丁媒体类型(除了了解表示本身的媒体类型之外(。
因此，在客户需要优化的情况下，使用PUT，然后使用PATCH作为替代方案进行补充，可能会更好，而不是相反。
如果你正在做一些非常具体的事情，那么一般指南可能不适用。
例如，如果您正在实现面向JSON:API客户端的JSON:API，那么您将希望使用PATCH，因为JSON:API在PUT的使用上有一个非常特殊的位置，而application/vnd.api+json指定了如何将其用作补丁文档。因此，对客户端和服务器理解相同补丁表示的关注"；离开"；。