PUT和PATCH的区别在于:

PUT必须是等幂的。为了实现这一点，您必须将整个完整的资源放在请求体中。 PATCH可以是非等幂的。这意味着在某些情况下它也可以是等幂的，比如你描述的情况。

PATCH需要一些“补丁语言”来告诉服务器如何修改资源。调用方和服务器需要定义一些“操作”，如“添加”、“替换”、“删除”。例如:

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@olddomain.example",
  "state": "NY",
  "zip": "10001"
}

PATCH /contacts/1
{
 [{"operation": "add", "field": "address", "value": "123 main street"},
  {"operation": "replace", "field": "email", "value": "abc@myemail.example"},
  {"operation": "delete", "field": "zip"}]
}

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "abc@myemail.example",
  "state": "NY",
  "address": "123 main street",
}

而不是使用显式的“操作”字段，补丁语言可以通过定义如下约定使其隐式:

PATCH请求体:

字段的存在意味着“替换”或“添加”该字段。 如果字段的值为空，则表示删除该字段。

使用上述约定，示例中的PATCH可以采用以下形式:

PATCH /contacts/1
{
  "address": "123 main street",
  "email": "abc@myemail.example",
  "zip":
}

这看起来更简洁和用户友好。但是用户需要了解底层的约定。

通过上面提到的运算，PATCH仍然是幂等的。但如果你定义像"increment"或"append"这样的操作，你可以很容易地看到它不再是幂等的。

我要补充的另一个信息是，PATCH请求比PUT请求使用更少的带宽，因为只发送了数据的一部分，而不是整个实体。因此，只需使用PATCH请求更新特定的记录(如(1-3条记录))，而使用PUT请求更新更大量的数据。就是这样，不要想太多，也不要太担心。

为了结束对幂等性的讨论，我应该指出，在REST上下文中可以用两种方式定义幂等性。让我们先确定一些事情:

资源是上域为字符串类的函数。换句话说，资源是String × Any的子集，其中所有的键都是唯一的。让我们将资源的类称为Res。

资源上的REST操作是一个函数f(x: Res, y: Res): Res。REST操作的两个例子是:

PUT(x: Res, y: Res): Res = x, and PATCH(x: Res, y: Res): Res，其工作原理类似PATCH({a: 2}， {a: 1, b: 3}) == {a: 2, b: 3}。

(这个定义是专门为讨论PUT和POST而设计的，例如，在GET和POST上没有多大意义，因为它不关心持久性)。

现在，通过固定x: Res(通俗地说，使用curry)， PUT(x: Res)和PATCH(x: Res)是类型为Res→Res的单变量函数。

当g〇g == g时，函数g: Res→Res称为全局幂等的，即对于任意y: Res, g(g(y)) = g(y)。 设x: Res一个资源，k = x.keys。函数g = f(x)称为左幂等，当对于每个y: Res，我们有g(g(y))|ₖ== g(y)|ₖ。它的意思是，如果我们看应用的键，结果应该是一样的。

PATCH(x)不是全局幂等的，而是左幂等的。左等幂是这里重要的东西:如果我们修补了资源的一些键，我们希望这些键在再次修补时是相同的，我们不关心资源的其他部分。

当RFC说PATCH不是等幂的时候，它说的是全局等幂。很好，它不是全局幂等的，否则它就是一个失败的运算。

现在，Jason Hoetger的答案试图证明PATCH甚至不是左幂等的，但它破坏了太多的东西:

First of all, PATCH is used on a set, although PATCH is defined to work on maps / dictionaries / key-value objects. If someone really wants to apply PATCH to sets, then there is a natural translation that should be used: t: Set<T> → Map<T, Boolean>, defined with x in A iff t(A)(x) == True. Using this definition, patching is left idempotent. In the example, this translation was not used, instead, the PATCH works like a POST. First of all, why is an ID generated for the object? And when is it generated? If the object is first compared to the elements of the set, and if no matching object is found, then the ID is generated, then again the program should work differently ({id: 1, email: "me@site.example"} must match with {email: "me@site.example"}, otherwise the program is always broken and the PATCH cannot possibly patch). If the ID is generated before checking against the set, again the program is broken.

我们可以通过打破这个例子中被打破的一半来证明PUT是非等幂的:

带有生成的附加特性的一个例子是版本控制。可以记录单个对象上的更改数量。在这种情况下，PUT不是幂等的:PUT /user/12 {email: "me@site.example"}第一次产生{email: "…"，version: 1}，第二次产生{email: "…"，version: 2}。 如果修改了ID，就可能在每次对象更新时生成一个新ID，从而产生一个非幂等PUT。

以上所有的例子都是人们可能会遇到的自然例子。

我的最后一点是，PATCH不应该是全局幂等的，否则不会给你想要的效果。您希望更改用户的电子邮件地址，而不涉及其余信息，并且不希望覆盖访问同一资源的另一方的更改。

让我更详细地引用和评论RFC 7231第4.2.2节，在之前的评论中已经引用过:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. (...) Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.

那么，在反复要求幂等方法之后，什么应该是“相同的”呢?不是服务器状态，也不是服务器响应，而是预期的效果。特别是，从客户的角度来看，该方法应该是幂等的。现在，我认为这个观点表明了Dan Lowe回答中的最后一个例子，我不想在这里抄袭，它确实表明PATCH请求可以是非幂等的(以一种比Jason Hoetger回答中的例子更自然的方式)。

实际上，让我们为第一个客户机明确一个可能的意图，从而使示例稍微精确一些。假设这个客户端遍历项目的用户列表，以检查他们的电子邮件和邮政编码。他从用户1开始，注意到zip是正确的，但电子邮件是错误的。他决定用PATCH请求来纠正这个问题，这个请求是完全合法的，只发送

PATCH /users/1
{"email": "skwee357@newdomain.example"}

因为这是唯一的修正。现在，由于一些网络问题，请求失败了，并在几个小时后自动重新提交。与此同时，另一个客户端(错误地)修改了用户1的zip文件。然后，第二次发送相同的PATCH请求并不能达到客户端的预期效果，因为我们最终得到了不正确的zip。因此，在RFC的意义上，该方法不是幂等的。

如果客户端使用PUT请求来更正电子邮件，将用户1的所有属性连同电子邮件一起发送给服务器，即使稍后必须重新发送请求并且同时修改了用户1，他也将达到预期的效果——因为第二个PUT请求将覆盖自第一个请求以来的所有更改。

这里有一个很好的解释

https://blog.segunolalive.com/posts/restful-api-design-%E2%80%94-put-vs-patch/: ~:文本= RFC % 205789,而不是% 20要求% 20 % 20 % 20幂等。

〇正常载荷 // 1号地块上的房子 ｛ 地址:“地块1” 老板:“根据”, 类型:“双”, 颜色:“绿色”, 房间:“5”, 厨房:' 1 ', windows: 20 ｝ PUT For Updated- // PUT请求有效载荷来更新plot 1上House的窗口 ｛ 地址:“地块1” 老板:“根据”, 类型:“双”, 颜色:“绿色”, 房间:“5”, 厨房:' 1 ', windows: 21 ｝ 注:在上述有效载荷中，我们试图将窗口从20更新到21。

现在查看PATH有效负载- //补丁请求有效载荷来更新House上的窗口 ｛ windows: 21 ｝

由于PATCH不是幂等的，失败的请求不会自动在网络上重新尝试。此外，如果PATCH请求是对一个不存在的url，例如试图替换一个不存在的建筑物的前门，它应该只是失败，而不像PUT那样创建一个新的资源，它会使用有效载荷创建一个新的资源。仔细想想，在一个住宅地址上只有一扇门是很奇怪的。

tl;博士版本

POST:用于创建实体 PUT:用于更新/替换一个现有的实体，您必须发送实体的整个表示，因为您希望它被存储 PATCH:用来更新一个实体，在这个实体中你只发送需要更新的字段