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.

虽然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))))。

TLDR -简化版

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请求将覆盖自第一个请求以来的所有更改。

PUT方法是理想的更新表格格式的数据，如在关系数据库或实体，如存储。基于用例，它可以用于部分更新数据或整体替换实体。它总是等幂的。

PATCH方法可用于更新(或重构)存储在本地文件系统或没有sql数据库的json或xml格式的数据。这可以通过在请求中提到要执行的动作/操作来执行，例如添加/删除/移动一个键值对到json对象。remove操作可用于删除键-值对，重复请求将导致错误，因为键之前已删除，使其成为非幂等方法。json数据补丁请求请参考RFC 6902。

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