首先，一些定义:
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?
