3 ms·
The PATCH verb seems underspecified and warty to me. Why not instead accept, on a PUT request, a Range header [1] whose byte-range-spec defines the range to be
by aaronem 13y ago
The PATCH verb seems underspecified and warty to
me. Why not instead accept, on a PUT request, a Range header [1] whose byte-range-spec defines the range to be replaced in the document? Along with an entity consisting
of the partial content to use in the replacement, this seems to provide everything the PATCH verb does, plus a
complete absence of the ambiguity involved in "[description of changes]".
Say maybe thus:
GET /users/123 HTTP/1.1
Host: www.example.com
Connection: keep-alive
HTTP/1.1 200 OK
Content-Type: text/json
Content-Length: 41
{"name":"Joe","email":"joe@example.com"}
PUT /users/123 HTTP/1.1
Host: www.example.com
Connection: keep-alive
Range: 24-27
j.random.hacker
HTTP/1.1 200 OK
Content-Type: text/json; charset=ISO-8859-1
Content-Length: 53
{"name":"Joe","email":"j.random.hacker@example.com"}
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
- wereHamster 13y agoHow would you patch multiple fields? Using json to patch json is more reliable. Also, if somebody changes the email before your request, your request will modify the document into an invalid json.
- aaronem 13y agoYou could handle multiple fields with Content-Type: multipart/byteranges and multiple byte-range-specs in the Range: header. The versioning problem can be trivially handled by means of the entity tag mechanism [1]. Our notional RFC need only specify that servers supporting partial PUT requests must include an ETag header [2] in every GET response, and that a client issuing a partial PUT request on a given resource must include an If-Match header [3] with the entity tag it received in its most recent GET response. The server can then compare the request's If-Match value with the current entity tag for the resource. If they match, the server updates the entity and responds with 204 No Content; otherwise, the server responds with 409 Conflict, whose response body is the complete entity and whose headers include the matching ETag, so that the UA can identify the conflict and present it to the user for resolution in whatever fashion it sees fit. Your point regarding blind byte-range modification of structured data ("Using json to patch json is more reliable") is not without merit, but belongs at a higher level of abstraction than that at which HTTP operates. If you want to take the JSON document through a thaw-edit-freeze cycle, you can do it on the client and just PUT the result as a complete entity. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11 http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.1... [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14... [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
- myhf 13y agoByte-ranges aren't idempotent like complete documents and key/value pairs are. You would need a vector-clock reference as well as the byte-range to let the server resolve ambiguity in your byte-range.
- aaronem 13y agoSee my response to wereHamster [1]; in short, you're right, which is why RFC 2616 specifies entity tags and the If-Match request header. [1] https://news.ycombinator.com/item?id=6494134 https://news.ycombinator.com/item?id=6494134