Take the 2-minute tour ×

I'm seeing a good bit of hand-waving on the subject of how to update only part of a resource (eg. status indicator) using REST.

The options seem to be:

  1. Complain that HTTP doesn't have a PATCH or MODIFY command. However, the accepted answer on http://stackoverflow.com/questions/1672025/http-modify-verb-for-rest does a good job of showing why that's not as good an idea as it might seem.

  2. Use POST with parameters and identify a method (eg. a parameter named "action"). Some suggestions are to specify an X-HTTP-Method-Override header with a self-defined method name. That seems to lead to the ugliness of switching within the implementation based on what you're trying to do, and to be open to the criticism of not being a particularly RESTful way to use POST. In fact, taking this approach starts to feel like an RPC-type interface.

  3. Use PUT to over-write a sub-resource of the resource which represents the specific attribute(s) to update. In fact, this is effectively an over-write of the sub-resource, which seems in line with the spirit of PUT.

At this point, I see #3 as the most reasonable option.

Is this a best practice or an anti-pattern? Are there other options?

share|improve this question

5 Answers 5

up vote 3 down vote accepted

Option 3 (PUT to some separated sub-resource) is your best bet right now, and it wouldn't necessarily be "wrong" to just use POST on the main resource itself - although you could disagree with that depending on how pedantic you want to be about it.

Stick with 3 and use more granular sub-resources, and if you really do have a need for PATCH-like behavior - use POST. Personally, I will still use this approach even if PATCH does actually end up as a viable option.

share|improve this answer

PATCH is fine for patch or diff formats. Until then it's not very useful at all.

As for your solution 2 with a custom method, be it in the request or in the headers, no no no no and no, it's awful :)

Only two ways that are valid are either to PUT the whole resource, with the sub data modified, or POST to that resource, or PUT to a sub-resource.

It all depends on the granularity of your resources and the intended consequences on caching.

share|improve this answer
you can use any format for PATCH that the server will accept. I use it with x-www-form-urlencoded for example –  Nicholas Nov 8 '12 at 15:10

It's ok to POST & emulating PATCH where not available

Before explaining this, it's probably worth mentioning that there's nothing wrong with using POST to do general updates (see here) In particular:


Really we should be using PATCH to make small updates to complex resources but it isn't as widely available as we'd like. We can emulated PATCH by using an additional attribute as part of a POST.

Our service needs to be open to third-party products such as SAP, Flex, Silverlight, Excel etc. That means that we have to use the lowest common denominator technology - for a while we weren't able to use PUT because only GET and POST were supported across all the client technologies.

The approach that I've gone with is to have a "_method=patch" as part of a POST request. The benefits are;

(a) It's easy to deal with on the server side - we're basically pretending that PATCH is available

(b) It indicates to third-parties that we are not violating REST but working around a limitation with the browser. It's also consistent with how PUT was handled a few years back by the Rails community so should be comprehensible by many

(c) It's easy to replace when PATCH becomes more widely available

(d) It's a pragmatic response to an awkward problem.

share|improve this answer
Our service needs to be open to third-party products such as SAP, Flex, Silverlight, Excel etc. That means that we have to use the lowest common denominator technology - for a while we weren't able to use PUT because only GET and POST were supported across all the client technologies - unfortunate but a reality. I thnk that using PUT but indicating that we really want to use PATCH is a reasonable compromise. –  Chris McCauley Feb 6 '10 at 10:38
PUT is a poor choice, since the primary distinction between non-safe verbs is idempotency. PUT is idempotent (as is DELETE) but PATCH is non idempotent (like POST) - so it makes far more sense to 'overload' POST... of course, 'just' using POST might be an idea since that works absolutely fine already, and the actual 'increase in visibility' you would get from introducing a method like PATCH is virtually nothing and not worth the effort or risk. –  Mike Feb 6 '10 at 11:19
The distinction that I find useful is that to me it is intuitive to PATCH directly to the resource URI. With POST I would prefer to post to a related "processing" resource, that applies the updates on my behalf. I agree that it is not a big difference but I don't forsee the mis-use that you do, so I'm ok with it :-) –  Darrel Miller Feb 6 '10 at 14:52
Sorry, meant to say POST –  Chris McCauley Feb 7 '10 at 9:43

HTTP does have a PATCH command. It is defined in Section of RFC 2068, and was updated in draft-dusseault-http-patch-16, currently awaiting publication as RFC.

share|improve this answer
In practice, it is probably better to stick to using POST instead for the time being, or just splitting out your resource into sub-resources and PUTing to those. –  Mike Feb 5 '10 at 16:39
Why is that better? A reason would be interesting... –  Julian Reschke Feb 5 '10 at 17:53
Lack of tooling. –  Mike Feb 6 '10 at 8:58
Whether lack of tooling is a problem certainly depends on the tools you have, right? So I'd recommend trying, instead of dismissing the option beforehand. –  Julian Reschke Feb 6 '10 at 9:02
PATCH addresses a tiny problem that was already solve-able with POST and some common sense - it's almost certainly going to be abused and damage the web (and any other system you allow it into) so I would just avoid it, it's not worth it. –  Mike Feb 6 '10 at 9:14

There are two ways to view a status update.

  1. Update to a thing. That's a PUT. Option 3

  2. Adding an additional log entry to the history of the thing. The list item in this sequence of log entries is the current status. That's a POST. Option 2.

If you're a data warehousing or functional programming type, you tend to be mistrustful of status changes, and like to POST a new piece of historical fact to a static, immutable thing. This does require distinguishing the thing from the history of the thing; leading to two tables.

Otherwise, you don't mind an "update" to alter the status of a thing and you're happy with a PUT. This does not distinguish between the thing and it's history, and keeps everything in one table.

Personally, I'm finding that I'm less and less trustful of mutable objects and PUT's (except for "error correction"). (And even then, I think the old thing can be left in place and the new thing added with a reference to the previous version of itself.)

If there's a status change, I think there should be a status log or history and there should be a POST to add a new entry to that history. There may be some optimization to reflect the "current" status in the object to which this applies, but that's just behind-the-scenes optimization.

share|improve this answer
Thanks for the reply. I should have been more selective about the example I used (i.e. status update). The problem I'm tackling is more general that just statuses. And, where it is a status I'm updating, it's really an update to show that the receiving system is in the process of working on the resource (like a confirmation). I'll be putting error checking to define allowable state transitions for the field. So, really, my situation fits your #1 (which is the original #3). –  Jacob Zwiers Feb 5 '10 at 17:56
If your data model doesn't have history, then, an update is the common fall-back plan. If you're still building, however, consider keeping all history. As an optimization, duplicating the most recent history in the thing itself. –  S.Lott Feb 5 '10 at 18:05

Your Answer


