rest - 如何在 REST 中支持部分更新 (PATCH)

Question

我想为我的资源实现部分更新，因为我有大量资源并想从中更新部分信息。我已经浏览了以下链接，但没有
能够确定是使用 HTTP POST 还是 PATCH 方法。

HTTP MODIFY verb for REST?

How to submit RESTful partial updates?

http://jacobian.org/writing/rest-worst-practices/

https://github.com/archiloque/rest-client/issues/79

http://tools.ietf.org/html/draft-dusseault-http-patch-16

http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html

http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch

http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates

https://github.com/dharmafly/jsonpatch.js

请为此提出任何有效的解决方案。

Answer 1

根据 RFC5789 ( http://tools.ietf.org/html/rfc5789 )，这正是 PATCH 的用途:

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

PATCH和PUT的区别描述为:

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.

还描述了 POST 的限制:

The PUT method is already defined to overwrite a resource with a complete new body, and cannot be reused to do partial changes. Otherwise, proxies and caches, and even clients and servers, may get confused as to the result of the operation. POST is already used but without broad interoperability (for one, there is no standard way to discover patch format support) [...]

我建议您阅读 RFC 并做出自己的决定，但对我来说这似乎相当明确 - PATCH 请求应作为部分更新处理。 (注意，与 PUT 不同，它们不是幂等的。)

编辑:正如尤金在评论中指出的，虽然 PATCH 请求是 "neither safe nor idempotent as defined by [RFC2616]" ，他们可以这样:

A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. Clients using this kind of patch application SHOULD use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH request.