4 ms·

PATCH Method for HTTP

32 points by mcantelon 17y ago

kvs 17y ago
I see something like Dropbox using it. Any other examples?
- deleted 17y ago
  [deleted]
jcapote 17y ago
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.
- sophacles 17y ago
  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.
- psadauskas 17y ago
  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.
  - jluxenberg 17y ago
    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.
tjpick 17y ago
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.
- DougWebb 17y ago
  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?
pkghost 17y ago
I thought POST was supposed to be the modify/edit verb of REST. Why add another one that browser makers won't implement?
- alexandros 17y ago
  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.
- derefr 17y ago
  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.
- deleted 17y ago
  [deleted]
kogir 17y ago
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 http://www.odata.org/developers/protocols/operations
- psadauskas 17y ago
  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.
  - kogir 17y ago
    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?
- _delirium 17y ago
  That set of use cases (adding semantics for resource modification to HTTP) is pretty much what WebDAV was designed for, wasn't it?
nileshtrivedi 17y ago
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.
- nileshtrivedi 17y ago
  < form method="patch" > should take care of it.
deleted 17y ago
[deleted]
m_eiman 17y ago
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?
- blasdel 17y ago
  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.
  - m_eiman 17y ago
    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.

32 points by mcantelon 17y ago

kvs 17y ago

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

deleted 17y ago
[deleted]

jcapote 17y ago

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.

sophacles 17y ago
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.
psadauskas 17y ago
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.
- jluxenberg 17y ago
  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.

tjpick 17y ago

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.

DougWebb 17y ago
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?

pkghost 17y ago

I thought POST was supposed to be the modify/edit verb of REST. Why add another one that browser makers won't implement?

alexandros 17y ago
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.
derefr 17y ago
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.
deleted 17y ago
[deleted]

kogir 17y ago

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 http://www.odata.org/developers/protocols/operations

psadauskas 17y ago
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.
- kogir 17y ago
  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?
_delirium 17y ago
That set of use cases (adding semantics for resource modification to HTTP) is pretty much what WebDAV was designed for, wasn't it?

nileshtrivedi 17y ago

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.

nileshtrivedi 17y ago
< form method="patch" > should take care of it.

deleted 17y ago

[deleted]

m_eiman 17y ago

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?

blasdel 17y ago
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.
- m_eiman 17y ago
  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.