

PATCH Method for HTTP - mcantelon
http://tools.ietf.org/html/rfc5789

======
kogir
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>

~~~
psadauskas
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
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?

------
tjpick
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
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
I thought POST was supposed to be the modify/edit verb of REST.

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

~~~
derefr
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.

------
m_eiman
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
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
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.

------
nileshtrivedi
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
< form method="patch" > should take care of it.

------
jcapote
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.

~~~
psadauskas
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
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.

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

