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

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

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

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

本文详细介绍了PATCH方法。

TLDR -简化版

PUT =>设置现有资源的所有新属性。

PATCH =>部分更新现有资源(不需要所有属性)。

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

假设你有以下元素:

{
  "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来修改一个元素(无论它是否真的是幂等的)。这是现实生活中经验的回归。