RESTful services and update operations

I know REST is meant to be resource-oriented, which roughly translates to CRUD operations on these resources using standard HTTP methods. But what I just wanted to update a part of a resource?

For example, let's say I have Payment resource and I wanted to mark its status as "paid". I don't want to POST the whole Payment object through HTTP (sometimes I don't even have all the data).

What would be the RESTful way of doing this? I've seen that Twitter uses the following approach for updating Twitter statuses:

http://api.twitter.com/1/statuses/update.xml?status=playing with cURL and the Twitter API

Is this app开发者_JS百科roach in "the spirit" of REST?

UPDATE: PUT -> POST

Some links I found in the meantime:

• PUT or POST: The REST of the Story
• PUT is not UPDATE
• PATCH Method for HTTP

---

The ideal way of doing this is to change a part (sub resource) of the resource and have the server return a 303 See Other with Location header to point to the altered resource. The 303 See Other tells the client that as the result of the request some other resource has changed and that the client should update the representation it holds.

In your example (media types hypothetical, of course):

1. Client retrieves payment representation
GET /payments/2

200 Ok
Content-Type: application/payment+xml

<payment>
  <status href="/payments/2/status" value="pending"/>
</payment>

2. Client updates status
PUT /payments/2/status
Content-Type: text/plain

payed

303 See Other
Location: /payments/2

3. Client follows the 303 redirect 
GET /payments/2

200 Ok
Content-Type: application/payment+xml

<payment>
  <status href="/payments/2/status" value="payed"/>
</payment>

---

POST should be used for modifying a resource

EDIT: Martin Fowler's article Richardson Maturity Model is a very good intro to REST.

---

What's wrong with PATCH? The "partial modification" issue seems to call for it, especially considering that sometimes you haven't got all the data needed to "replace it"... But honestly, I see no point in following the "POST = create, PUT = replace, PATCH = update" philosophy religiously, and I see nothing wrong in using only POST.

---

I guess, that's what POST is for: The 'U' in 'CRUD'.

You POST data to an existing resource. The resource decides what to do with it, and gets updated. Also, the POST data may be only a fragment of the complete resource.

Twitter's approach is IMHO not RESTful, because they overload GET.