Does REST/HTTP Need a PATCH Method?
There’s quite a debate going on on whether and if so, how, to standardize a PATCH method for HTTP. James Snell, who edits the draft spec, has a list of links to posts that make up the discussion.
I’m unsure I’d be happy about a PATCH method; my main gripe with it is that its semantics heavily depend on the content being sent (which needs to be some sort of diff format matching one of the resource’s representation formats). Right now, I agree with Dare Obasanjo:
If a field is important enough that it needs to be identifiable and editable then it should be its own resource.
Wouldn’t decentralizing media types obviate the need for this? Nothing in the specs say that the payload format for a given URL must match for different verbs anyway. The specs do say that PUT is meant to replace an entire resource. Many people believe that requires/infers payload symmetry with GET. I don’t personally believe that, but we’ve ducked the issue by not using PUT at all (we’ll probably change that). POST is there as a catch-all update already and the W3C was wise not to go too far to define its semantics.
If you have multiple formats for updating resources, maybe you indicate which mechanism the caller is using through a media type value or (for XML) in a namespace declaration. But you can’t just add PATCH without making it clear when to use it vs. POST and I don’t think the W3C will come to consensus about that.
BTW, I agree with Dare that it’s useful for fields to be addressable as resources. But it doesn’t help all that much if your application typically needs to updates 15 out of the 200 fields in the resource.
The thing is that people want transactional updates, i.e., all or none semantics (C in ACID).
If you have twenty nested resources with their own URL, you cannot change all (or some) of them at once - if you fail at PUT request #17, the first 16 are broken in some way.
I think this will be difficult - it’s highly dependent on application semantics etc. And it might actually make more sense to handle this kind of operation in a service way, not in a resource way, as what you want is a mass-(rename|delete|change|…)-operation, rather than a resource change.
“Right now, I agree with Dare Obasanjo:”
I guess one thing is that you’re breaking up your resources based on the details of the representation (eg, what Dare is saying isn’t entirely necessary with RDF/XML, nor is a diff format - you can send individual triples). That doesn’t seem like a good coupling. Another is resource composition. Even though you want to do fine grained editing, you might not want fine grained access (and probably taking on all the associated atomic/consistency issues) - cue Patrick Mueller’s point about resource composition. Another is, I’m not sure it captures a real use-case; not one requirement I have right now for partial uploads/updates is about picking out XML elements and just sending those. Another is field/document addressing - sure seems like a great idea, until you look at the debacle around HTML fragment identifiers. I think this needs to considered in terms of tradeoffs, like any optimization.
I find it very interesting, and a nice addition to HTTP at least (not sure its real application to REST at the moment). As for your worrying about the patch depending on the content, that’s the whole thing with HTTP, right? You have the content-type field to tell what you’re transferring. The same can be applied to patches…
In fact, the PATCH it is actually a POST with optimistically believed shared knowledge with the server.
Regards, diego.