05/03/08 :: [SOA] Roy's Post [permalink]
Subbu pointed to a really interesting post from Roy Fielding.
There seems to be a common thread with most posts here. People have been busy modeling everything as a resource and now they want to know how to do everything in a PUT or DELETE instead of any of the other HTTP methods. That is wrong.
REST is not limited to GET, PUT, and DELETE. Anyone who says so is just making things up as they go along.
REST is limited to the client being told what to do next by the current state of where they are now, aside from the entry point(s) we call a bookmark.
That is feasible because the set of methods is uniform, not because it is limited to CRUD.
If you read the (other) REST community bible, the RESTful Web Services book, all they recommend is to use REST to create a Data Access Layer, so they mostly GET, PUT and DELETE. Unless I am mistaken, I also heard most of the people in the (other) REST community talk about how bad "POST" was, not to mention how a WADLization of the resources would be a tragic design mistake.
I have heard so many times that there is no "actions" in REST that you simply "PUT" resource representations back or new resources in collections at will.
I must admit that your post is refreshing, though I would still need some clarification about the "Client is being told what to do next". As I have explained many times, this makes perfect sense when the client is a browser operated by a human. When the client is a (mundane) piece of code, I would be really curious to understand your opinion on how much "coupling" is needed in that case, and how this coupling would materialize (in relation to the uniform interface).