HTTP MODIFY verb for REST?

Question

As far as I see, there's no RESTful way to apply a modification to a resource. In order to do it, you have to PUT the resource as a whole, overwriting the previous representation. I think this is source of problems, in particular when the resource has a large representation.

I believe this hints at the lack of a verb in HTTP1.1 : something like MODIFY, or PATCH. Not even WebDAV has this verb (it has PROPPATCH, whose concept is similar, but not for the resources).

Isn't the current HTTP 1.1 set of verbs too limited for real world RESTing ?

Edit: I found a proposal at IETF about the PATCH verb

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

This specification defines the new HTTP/1.1 [RFC2616] method PATCH that is used to apply partial modifications to a resource.

A new method is necessary to improve interoperability and prevent errors. The PUT method is already defined to overwrite a resource with a complete new body, and can not 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. PATCH was mentioned in earlier HTTP specifications, but not completely defined.

As far as I see, the only problem of such a verb is lack of idempotency.

Edit: As of March 2010, RFC 5789 exists (PATCH Method for HTTP).

Answer 1

There is good reason there is no such verb to do this. It's almost impossible to manage. Think of 100's of clients modifying the same resource in this way, how do you know where your modification ends up? What if order matters, and your "patch" is actually added after another "patch" and now what you meant to add i actually not what was added. Using PUT with ETag headers is a much more sane approach to modifying a resource then trying to hobble together some new verb with unknown results. Having to actually GET the resource is a small price to pay for repeatable results.

Answer 2

I wish there were standardized and supported verbs like...

• FIND, SEARCH, or QUERY - so its clear the request is not for a resource, but the locations of other resources. Maybe only limited usefulness.
• MOVE, COPY, LINK - just damn handy, they'd act similar to the command line tools.
• DISCOVER, MAP, INDEX, or SITEMAP - so you can get a layout of resources, similar in concept to a wsdl file, or xmlrpc's system.listMethods.
• BEGIN, ACQUIRE, or LOCK, and COMMIT, END, DONE, or RELEASE - to make it clear when you're starting and ending transactions, or using intermediate resources.
• MODIFY, UPDATE, PATCH - because we all want it

Answer 3

You can use POST for partial updates. It's not ideal, but it's fairly RESTful.

Answer 4

You could partition the resource into individually updatable sub-resources.

E.g. you have a /user resource representing user account information you could create a /user/email sub-resource, then do a PUT on it to update just the email.