虽然Dan Lowe的精彩回答非常彻底地回答了OP关于PUT和PATCH之间区别的问题，但它对PATCH为什么不是幂等的问题的回答并不完全正确。

为了说明为什么PATCH不是幂等的，它有助于从幂等的定义开始(来自维基百科):

幂等这个术语更广泛地用于描述一个操作，如果执行一次或多次将产生相同的结果[…]幂等函数对于任意值x具有f(f(x)) = f(x)的性质。

在更容易理解的语言中，幂等PATCH可以定义为:在使用补丁文档修补一个资源之后，所有后续使用相同补丁文档对同一资源的PATCH调用都不会改变该资源。

相反，一个非幂等的操作是f(f(x)) != f(x)，对于PATCH来说，它可以表述为:在用补丁文档修补一个资源之后，后续的PATCH调用使用相同的补丁文档对同一资源进行更改。

为了说明一个非幂等PATCH，假设有一个/users资源，并且假设调用GET /users返回一个用户列表，当前:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" }]

假设服务器允许修补/users，而不是像OP的例子中那样修补/users/{id}。让我们发出这个PATCH请求:

PATCH /users
[{ "op": "add", "username": "newuser", "email": "newuser@example.org" }]

我们的补丁文档指示服务器将一个名为newuser的新用户添加到用户列表中。第一次调用后，GET /users将返回:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" }]

现在，如果我们发出与上面完全相同的PATCH请求，会发生什么?(为了便于本例，我们假设/users资源允许重复用户名。)“op”是“add”，所以一个新用户被添加到列表中，并且后续的GET /users返回:

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" },
 { "id": 3, "username": "newuser", "email": "newuser@example.org" }]

/users资源再次发生了变化，尽管我们对完全相同的端点发出了完全相同的PATCH。如果PATCH是f(x) f(f(x))不等于f(x)因此，这个PATCH不是幂等的。

尽管PATCH不能保证是幂等的，但PATCH规范中没有任何内容可以阻止您在特定服务器上执行所有PATCH操作。RFC 5789甚至预测了幂等PATCH请求的优势:

PATCH请求可以以一种幂等的方式发出， 这也有助于防止两者相撞的坏结果 PATCH请求在相同的时间范围内对相同的资源。

在Dan的例子中，他的PATCH操作实际上是等幂的。在那个例子中，/users/1实体在我们的PATCH请求之间发生了变化，但不是因为我们的PATCH请求;实际上是邮局的不同补丁文件导致邮政编码发生变化。邮局不同的PATCH是不同的操作;如果我们的PATCH是f(x)，邮局的PATCH就是g(x)。幂等性说明f(f(f(x))) = f(x)，但不保证f(g(f(x))))。

Everyone else has answered the PUT vs PATCH. I was just going to answer what part of the title of the original question asks: "... in REST API real life scenarios". In the real world, this happened to me with internet application that had a RESTful server and a relational database with a Customer table that was "wide" (about 40 columns). I mistakenly used PUT but had assumed it was like a SQL Update command and had not filled out all the columns. Problems: 1) Some columns were optional (so blank was valid answer), 2) many columns rarely changed, 3) some columns the user was not allowed to change such as time stamp of Last Purchase Date, 4) one column was a free-form text "Comments" column that users diligently filled with half-page customer services comments like spouses name to ask about OR usual order, 5) I was working on an internet app at time and there was worry about packet size.

The disadvantage of PUT is that it forces you to send a large packet of info (all columns including the entire Comments column, even though only a few things changed) AND multi-user issue of 2+ users editing the same customer simultaneously (so last one to press Update wins). The disadvantage of PATCH is that you have to keep track on the view/screen side of what changed and have some intelligence to send only the parts that changed. Patch's multi-user issue is limited to editing the same column(s) of same customer.

我对此也很好奇，并找到了一些有趣的文章。我可能不能完全回答你的问题，但至少提供了一些信息。

http://restful-api-design.readthedocs.org/en/latest/methods.html

HTTP RFC指定PUT必须接受一个全新的资源 表示为请求实体。这意味着如果举个例子 只提供了某些属性，这些属性应该被删除(即设置 为null)。

鉴于此，PUT应该发送整个对象。例如,

/users/1
PUT {id: 1, username: 'skwee357', email: 'newemail@domain.example'}

这将有效地更新电子邮件。PUT可能不太有效的原因是，只修改一个字段并包括用户名是无用的。下一个例子显示了区别。

/users/1
PUT {id: 1, email: 'newemail@domain.example'}

现在，如果PUT是根据规范设计的，那么PUT将把用户名设置为null，您将得到以下结果。

{id: 1, username: null, email: 'newemail@domain.example'}

当您使用PATCH时，您只更新您指定的字段，其余的保持不变。

以下对PATCH的看法与我以前从未见过的略有不同。

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

PATCH /users/123

[
    { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

您或多或少地将PATCH视为更新字段的一种方式。所以你发送的不是部分对象，而是操作。例如，用价值取代电子邮件。

文章的结尾是这样的。

值得一提的是PATCH并不是真正为REST设计的 api，因为Fielding的论文没有定义任何方法来部分 修改资源。但是Roy Fielding自己说PATCH是 这是他为最初的HTTP/1.1提案创建的，因为 partial PUT从来不是RESTful的。确定你没有转移一个完整的 表示，但是REST不需要表示 完成了。

现在，我不知道我是否像许多评论员指出的那样特别同意这篇文章。发送部分表示可以很容易地成为更改的描述。

对我来说，我不太喜欢使用PATCH。在大多数情况下，我将把PUT视为PATCH，因为到目前为止我注意到的唯一真正的区别是PUT“应该”将缺失的值设置为null。这可能不是“最正确”的方法，但祝你好运，能写出完美的代码。

这里有一个很好的解释

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:用来更新一个实体，在这个实体中你只发送需要更新的字段

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"这样的操作，你可以很容易地看到它不再是幂等的。