为了结束对幂等性的讨论，我应该指出，在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请求将覆盖自第一个请求以来的所有更改。

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.

考虑到你关于等幂的问题，我可能有点跑题了，但我希望你考虑一下进化论。

假设你有以下元素:

{
  "username": "skwee357",
  "email": "skwee357@domain.example"
}

如果你使用PUT进行修改，你必须给出对象的完整表示:

PUT /users/1
{
  "username": "skwee357",
  "email": "skwee357@newdomain.example"
}

现在更新模式，并添加一个现场电话:

PUT /users/1
{
  "username": "skwee357",
  "email": "skwee357@newdomain.example",
  "phone": "123-456-7890"
}

现在用PUT以同样的方式再次更新它，它将设置phone为null。为了避免这种坏的副作用，您必须在每次更新模式时更新所有修改元素的组件。站不住脚的。

使用PATCH就不会有这个问题，因为PATCH只更新给定的字段。因此，在我看来，您应该使用PATCH来修改一个元素(无论它是否真的是幂等的)。这是现实生活中经验的回归。

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

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

本文详细介绍了PATCH方法。

这里有一个很好的解释

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那样创建一个新的资源，它会使用有效载荷创建一个新的资源。仔细想想，在一个住宅地址上只有一扇门是很奇怪的。