Update: a proposal for a better name.
Don Box got people talking last week in a posting where he distinguishes between two kinds of REST: lo-REST, which uses only HTTP GET and POST, and hi-REST, which also uses HTTP PUT and DELETE.
The schism
If this distinction doesn’t seem very important, don’t worry — it’s not. Tim Bray captured the most important point, that Don Box (who is heavily involved in REST’s nemesis, Web Services) is talking positively about REST at all. For the RESTafarians and some of their friends, however, Box’s heresy was even worse than his former non-belief, because heresy can easily lead the faithful astray: witness strong reactions from Dimitri Glazkov, Jonnay (both via Dare Obasanjo), and Dare Obasanjo himself. There is even a holy scripture, frequently cited to clinch arguments.
The contradiction
I do not yet have a strong opinion on which approach is better, but I do see a contradiction between the two arguments I hear most often from REST supporters:
- REST is superior to Web Services/SOAP/SOA because it’s been proven to work on the Web.
- Almost nobody on the Web uses REST correctly.
Pick one, and only one of these arguments, please. As far as I can see, apart from a few rare exceptions (like WebDAV), Don’s lo-REST — HTTP GET and POST only — is what’s been proven on the web. The pure Book of Fielding, hi-REST GET/POST/PUT/DELETE version is every bit as speculative and unproven as Web Services/SOAP/SOA themselves (that’s not to say that it’s wrong; simply that it’s unproven). Some REST supportors, like Ryan Tomayko, acknowledge this contradiction.
(Update) A better name?
Tim Bray proposes throwing out the REST name altogether and talking instead about Web Style. I like that idea, though the REST name may be too sticky to get rid of by now. Dumping the REST dogma along with the name would clear up a lot of confusion: HTTP GET and POST have actually been proven to work and scale across almost unimaginable volumes; on the other hand, like the WS-* stack, using HTTP PUT and DELETE remains a clever design idea that still needs to be proven practical and scalable.
Quoderat 
Pingback: Restiness
I think it’s important to note that what’s demonstrated to work is indeed GET and POST, but *GET and POST as defined*. I suspect that when Don says “POST” he’s implicitly encompassing both tunneled and non-tunneled uses of POST.
Also, GET and POST used as defined is RESTful, and nothing in REST says that you have to use all methods. It only says you have to use the right one for the job (per self-description). If you only need to get data, or submit it for processing, then only using GET and POST is just fine.
If someone came out with a plain way to describe how to create a “restful API” and gave it a name (a la “Ajax”), people would switch to it in a second. The problem is that REST’s current primary documentation is a doctoral dissertation that is mostly unintelligible to a normal human being.
Secondly, REST backers need to come to a conclusion on whether ot not PUT is necessary (no one ever DELETEs).
Finally, once there is some common understanding of (the son of) REST, we should document how some popular APIs would look (e.g., Amazon, Flickr, Bloglines, etc.).
I stay out of the REST is better then WS-* argument, because I don’t have any firm numbers to state which is better. I personally prefer REST.
My problem was that defining REST in terms of HTTP verbs is missing the whole point of rest.