PATCH Method for HTTP | Hacker News Reader

PATCH Method for HTTP

tools.ietf.org

32 pointsmcantelon19 comments

There is a real need for this in collection oriented REST interfaces. While PUTing the individual properties is possible, it doesn't allow you to

  1) Commit a set of changes together as a single transaction
  2) Commit a set of changes in a single HTTP request (latency matters)

And yes, you can just PUT the whole thing, unless one of the properties you aren't updating is a 4MB image, or 500MB video.

I'm working with a REST framework where the authors have been forced to use a custom verb (MERGE) to provide this functionality. See http://www.odata.org/developers/protocols/operations

So why not just separate the video from the metadata? The PUT would a be small thing thats easy to replace, and contains a link to the video elsewhere.

Ok, bad example.

Imagine an item for sale that has 100KB of text as a description. Does it really make sense to link to the description text rather than keep it along with the name, price, etc?

Does it make sense to update it every time from say, a mobile client?

That set of use cases (adding semantics for resource modification to HTTP) is pretty much what WebDAV was designed for, wasn't it?

If you treat the document as a collection, you can usually map a url to the particular property that needs updating and accept PUT to that. But that can be a pain if you don't know in advance which particular properties will be updated.

I could also see implementing a server that accepts PUT with a diff format and just apply that patch instead of replacing the document.

Some of it seems well thought out but there are other bits that smell a bit fishy to me

> For example, if the patch document size is larger than the size of the new resource data that would be used in a PUT, then it might make sense to use PUT instead of PATCH.

On one of my projects I did something like this. I needed to create a resource atomically even though it was composed of many files. To accomplish this I established a container resource that the client could PUT to with a tar.gz file, and the service would unpack the files into the container.

The body of a PUT request is intended to specify a new representation for the resource, but there's nothing in the standards that say that the format of the PUT body has to match the final resource. Gzipping, compressing, and chunking the representation as it travels back and forth are explicitly supported, so why not PUT a representation that represents the differences between the old and new version of the resource?

I thought POST was supposed to be the modify/edit verb of REST.

Why add another one that browser makers won't implement?

POST is the wildcard verb when you can't use anything else. PATCHing seemed to be a common enough use case to warrant standardising. PATCH, combined with ETags, offers idempotentcy meaning that if you are unsure of success you can simply repeat the operation. This can really come in handy in a distributed system working over a network. (PUT and DELETE have this property, POST does not) Also, when intermediaries can understand what you're doing, they can handle caching much better, invalidating what they must, etc. Again, POST does not give you that luxury.

I think the problem is that, now, POST means something more like "send the resource a message, as if it were an OOP-style object." Anything can happen when you POST.

PATCH is just, well, a patch—;)—to get back to the original semantics of POST, since with people using POST the way they currently do, those semantics (for things like caching) are unreliable.

Wouldn't it be easier to use a PUT with a Transfer-Encoding of "text/x-diff" (or some such) and an If-Match header?

No, because PUT is defined as something entirely different — multiple identical PUT requests on the same resource at different times should always transfer the same state and have the same response.

PUT is also defined such that the body contains the whole resource, ideally in a Content-Encoding that you can GET with an appropriate Accept header.

Multiple identical PUT requests with Transfer-Encoding:diff+If-Match will result in the same thing as a "normal" PUT with an If-Match header - if the resource is in the matched state it will be transformed, and if it isn't it will be unchanged.

The Transfer-Encoding:diff+If-Match combo is in effect the same thing as sending the whole data blob, it's just an efficient transfer compression. No different than Transfer-Encoding:gzip; the data sent isn't the data to be stored until its Transfer-Encoding has been reversed.

This could be implemented beautifully if the form tag accepts a parameter "patch", which would, when set to true, only send the fields and values which were actually modified by the user and not the whole bunch of fields in the edit form.

< form method="patch" > should take care of it.

It seems like PATCH could be implemented as a PUT to a resource that represents the transformation of some other complete resource, allowing you to just PUT the changes as opposed to the whole document.

That seems to break the REST metaphor of nouns and verbs, at least it strains it. I mean sure, a noun of "transmogrifier" is fine, and if you put something in there, it can be reasonably expected to undergo transmogrification. However, just allowing a "change it" verb on a resource seems a bit more direct.

A PUT is already well-defined, and more importantly, idempotent. Adding PATCH-like behavior would not be repeatable, and would break every HTTP server, client, and proxy out there.

PATCH, like PUT, can be used in an idempotent manner using the "If-Matches" header. If the content being PATCHed matches a given ETag, then the path will be applied, otherwise the path will not be applied and a 412 Precondition Failed should be returned.

I see something like Dropbox using it. Any other examples?

Reply on news.ycombinator.com