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.

我要补充的另一个信息是，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不应该是全局幂等的，否则不会给你想要的效果。您希望更改用户的电子邮件地址，而不涉及其余信息，并且不希望覆盖访问同一资源的另一方的更改。

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

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

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。这可能不是“最正确”的方法，但祝你好运，能写出完美的代码。

在我看来，幂等性意味着:

把:

我发送了一个竞争资源定义，因此-结果资源状态与PUT参数所定义的完全相同。每次我用相同的PUT参数更新资源时——结果状态完全相同。

补丁:

我只发送了资源定义的一部分，所以可能会发生其他用户正在更新此资源的other参数。因此，具有相同参数及其值的连续补丁可能导致不同的资源状态。例如:

假设一个对象定义如下:

汽车: -颜色:黑色， -类型:轿车， -座位:5个

我用:

{颜色:“红色”}

结果对象是:

汽车: -颜色:红色， -类型:轿车， -座位:5个

然后，其他一些用户给这辆车打了补丁:

{类型:“掀背车”}

因此，结果对象是:

汽车: -颜色:红色， -类型:掀背式， -座位:5个

现在，如果我再次修补这个对象:

{颜色:“红色”}

结果对象是:

汽车: -颜色:红色， -类型:掀背式， -座位:5个

与我之前得到的有什么不同!

这就是为什么PATCH不是幂等的，而PUT是幂等的。