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.