Sam Ruby，“RESTful Web Services”的作者似乎反对使用 HTTP PUT 进行部分更新：http: //intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate
尚不清楚应该如何进行部分更新。正如我在他的博客底部评论的那样，目前尚不清楚使用 HTTP PATCH 比使用“补丁文档”对抗 HTTP PUT 更好。
值得注意的是，尽管 Sam 反对滥用 HTTP PUT，但他似乎也不提倡使用 HTTP PATCH。
应该如何提交 RESTful 部分更新？
正如您从您引用的博客文章中的评论中看到的那样，没有就进行部分更新的方式达成一致。如果像 Sam Ruby、Joe Gregario、Mark Nottingham、Mark Pilgrim、Bill de hÓra 等重量级人物无法达成协议，我们还有什么希望。
就我而言，我不会太担心。创建适合您的部分更新媒体类型，使用 PATCH 来表明您的意图，当最终就通用媒体类型达成一致时，更改您的服务器以接受这两种格式。
值得庆幸的是，如果您的 REST api 犯下的最严重的罪行是滥用 PUT/PATCH，那么您做得很好。
现在是 2013 年 - 您应该使用 PATCH 进行部分更新 - 使用 json-patch（参见https://www.rfc-editor.org/rfc/rfc6902或http://www.mnot.net/blog/2012 /09/05/patch）或 xml-patch 文档（参见https://www.rfc-editor.org/rfc/rfc7351）。不过，在我看来，json-patch 最适合您的业务数据类型。
带有 JSON/XML 补丁文档的 PATCH 对于部分更新具有非常严格的前向语义。如果您开始使用带有原始文档的修改副本的 POST 进行部分更新，您很快就会遇到您希望缺失值（或者更确切地说是空值）表示“忽略此属性”或“将此属性设置为空值” - 这导致了黑客解决方案的兔子洞，最终将导致您自己的补丁格式。
您可以在这里找到更深入的答案：http: //soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html。
更新：这是 RPC 吗？
好吧，如果您将 RPC 定义为向服务器发送命令，那么任何和所有 HTTP 操作都是 RPC 调用 - 无论您是 GET 资源、PUT 新表示还是再次删除它 - 它们中的每一个都包含发送命令（动词）GET /PUT/DELETE 等和可选的有效负载。碰巧 HTTP 工作组（或者它是谁）引入了一个新动词 PATCH，它允许客户端对资源进行部分更新。
如果除了将完整的表示发送到服务器之外，其他任何东西都被认为是 RPC 样式，那么根据定义，部分更新不能是 RESTful。可以选择持有这种观点，但网络基础设施背后的人说不同 - 因此为此目的定义了一个新动词。
RPC 更多地是关于通过 HTTP 以对 Web 上的中介不可见的方式调用方法调用——例如使用 SOAP 来包装方法名称和参数。这些操作是“不可见的”，因为没有标准定义有效载荷内的方法和参数。
将其与具有媒体类型 application/json-patch 的 PATCH 进行比较 - 由于动词 PATCH 具有明确定义的含义，并且有效负载以另一种明确定义的公共可用格式编码，因此网络上的任何中介都清楚地看到了操作的意图通过网络上的共同权威 (IETF)。最终结果是每个人都完全可见，并且没有特定于应用程序的秘密语义。
REST 也是关于“偶然重用”，这正是 PATCH with application/json-patch 的含义——重用现有标准，而不是发明或多或少相同的应用程序特定协议。
您可以为部分资源提供自己的 URI，而不是自制部分更新媒体类型并使用非标准 PATCH 方法。
HTTP PATCH 现在有一个 RFC - HTTP PATCH RFC