在REST API实际场景中使用PUT与PATCH方法
首先，一些定义： PUT在9.6节RFC 2616中定义： PUT方法请求将封闭的实体存储在提供的Request-URI下。如果Request-URI引用了已经存在的资源，则应将封闭的实体视为原始服务器上的资源的修改版本。如果Request-URI没有指向现有资源，并且请求用户代理能够将该URI定义为新资源，则原始服务器可以使用该URI创建资源。 PATCH在RFC 5789中定义： PATCH方法请求将在请求实体中描述的一组更改应用于由Request-URI标识的资源。 同样根据RFC 2616第9.1.2节， PUT是幂等的，而PATCH不是。 现在让我们看一个真实的例子。当我/users对数据执行POST {username: 'skwee357', email: 'skwee357@domain.com'}并服务器能够创建资源时，它将以201和资源位置（假设/users/1）响应，并且对GET的下一次调用/users/1将返回{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}。 现在，让我们说我想修改我的电子邮件。电子邮件修改被视为“一组更改”，因此我应该/users/1使用“ 补丁文档 ”来进行修补。在我的情况下，它将是json文档：{email: 'skwee357@newdomain.com'}。然后，服务器返回200（假设允许）。这使我想到第一个问题： 补丁不是幂等的。它在RFC 2616和RFC 5789中是这样说的。但是，如果我发出相同的PATCH请求（使用我的新电子邮件），我将获得相同的资源状态（将我的电子邮件修改为请求的值）。为什么PATCH不那么幂等？ PATCH是一个相对较新的动词（2010年3月引入RFC），用于解决“修补”或修改一组字段的问题。在引入PATCH之前，每个人都使用PUT来更新资源。但是在引入PATCH之后，我对PUT的用途感到困惑。这使我想到了第二个（也是主要的）问题： PUT和PATCH之间的真正区别是什么？我在某处读到了PUT可能用于替换特定资源下的整个实体，因此应该发送完整的实体（而不是像PATCH那样发送一组属性）。这种情况的实际实际用途是什么？您何时要替换/覆盖特定资源URI上的实体，为什么不考虑将此类操作更新/修补该实体？我在PUT上看到的唯一实际用例是在集合上发布PUT，即/users替换整个集合。引入PATCH之后，在特定实体上发布PUT毫无意义。我错了吗？