首先，一些定义:
PUT的定义见章节9.6 RFC 2616:
PUT方法要求将所包含的实体存储在所提供的Request-URI下。如果Request-URI引用了一个已经存在的资源，那么所包含的实体应该被认为是原始服务器上的实体的修改版本。如果Request-URI不指向现有资源，并且请求用户代理能够将该URI定义为新资源，则源服务器可以使用该URI创建资源。
PATCH在RFC 5789中定义:
方法中描述的一组更改
请求实体应用于由request -标识的资源
URI。
此外，根据RFC 2616节9.1.2 PUT是等幂的，而PATCH不是。
现在让我们看一个真实的例子。当我用数据{用户名:'skwee357'，电子邮件:'skwee357@domain.example'} POST到/users时，服务器能够创建资源，它将响应201和资源位置(让我们假设/users/1)，任何下一次调用GET /users/1将返回{id: 1，用户名:'skwee357'，电子邮件:'skwee357@domain.example'}。
现在假设我想修改我的电子邮件。邮件修改被认为是“一组更改”，因此我应该用“补丁文档”PATCH /users/1。在我的例子中，它将是JSON文档:{email: 'skwee357@newdomain.example'}。然后服务器返回200(假设权限正常)。这让我想到了第一个问题:
PATCH不是等幂的。RFC 2616和RFC 5789都是这么说的。但是，如果我发出相同的PATCH请求(用我的新电子邮件)，我将获得相同的资源状态(我的电子邮件被修改为所请求的值)。为什么PATCH不是幂等的?
PATCH是一个相对较新的动词(RFC于2010年3月引入)，它用来解决“修补”或修改一组字段的问题。在PATCH引入之前，每个人都使用PUT来更新资源。但是在引入PATCH之后，它让我对PUT的用途感到困惑。这就引出了我的第二个(也是主要的)问题:
What is the real difference between PUT and PATCH? I have read somewhere that PUT might be used to replace entire entity under specific resource, so one should send the full entity (instead of set of attributes as with PATCH). What is the real practical usage for such case? When would you like to replace / overwrite an entity at a specific resource URI and why is such an operation not considered updating / patching the entity? The only practical use case I see for PUT is issuing a PUT on a collection, i.e. /users to replace the entire collection. Issuing PUT on a specific entity makes no sense after PATCH was introduced. Am I wrong?
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"这样的操作，你可以很容易地看到它不再是幂等的。
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.
