Calling HTTP GET and POST ‘verbs’ is a gross misnomer; they really are URI metadata in disguise.
REST is centered around the idea that we should use the way the web works when we do things on the Web – fair enough – and that REST is the architectural style of the Web. RESTful applications – like HTTP – use POST, GET, PUT and DELETE to CREATE, READ, UPDATE and DELETE resources.
The problem is, this is not how the current Web works.Real verbs can be applied to many nouns, and a single noun can take many verbs: the cat walks, the cat talks, the cat whines, the cat shines. Some combinations make no sense, but a lot do. This is not the case for GET and POST and their friends. In principle, it is possible to apply both GET and POST to a single resource; GET an EMPLOYEE record, POST to the same record.
In practice GET and POST do not often apply to the same resource. POST on the Web is used in HTML forms. A form has a method (GET or POST) and an URI (which points to a resource). Usually, POST forms have unique URI’s; they don’t share them with GETS. Amazon uses artificial keys to make the POST URI’s unique. More surprising, they even do the same thing when I GET the URI instead of POST it (which the Firefox Web Developer toolbar supports with a single menu choice). Amazon doesn’t care whether I GET or POST a book to my shopping cart; it (understandably) lands in my shopping cart either way. The same applies to del.icio.us and numerous other – I suspect most – sites.
The Web does not work through applying a small set of verbs to a large number of resources: the resources do all the work. GET and POST aren’t real verbs; they just signal what the URI owner intends to do when the URI is dereferenced; as such, they are URI metadata. The ‘GET’ metadata in a HTML form’s method just informs your browser, and all intermediaries that this URI is supposed to have no side-effects on the server. Of course no browser can know what actually happens when a URI is dereferenced: maybe a document is returned, maybe the missiles are fired. GET and POST are just assertions made by the URI owner about the side effects of the URI.
The ‘old’ Web wouldn’t be one bit different in appearance if both GET and POST weren’t even allowed on the same URI. It’s possible to use them as real verbs, as REST advocates; but the merits of this approach do not derive from the way the current Web works.
Don’t get me wrong: GET and POST are brilliant – especially GET. Returning the GET and POST metadata back to the server with the URI is what makes the Web tick: it allows intermediaries to do smart caching stuff, based on the GET and POST metadata. But however good – GET and POST are not verbs, they are metadata.
> The problem is, this is not how the current Web works.
I couldn’t agree more. When RESTafarians claim that REST obviously works because the web works so well they are missing the point, because, as you say, the current web doesn’t use REST.
So there isn’t really just a choice between SOAP and REST. The choice is really SOAP, REST, or plain HTTP. When we made the TMRAP Topic Maps “protocol” we gave it a SOAP interpretation and a plain HTTP interpretation. The latter was not REST by any stretch of the imagination, but it was exactly the way the current web works.
Of course, you could claim that REST is better, and for many situations it’s true that REST is very clean, but it’s not always convenient to make your web protocol RESTy.
Hello.
I just want to comment on your cat example.
If you consider “cat” your resource, then GET, POST, PUT and DELETE (GPPD, for short) make sense. Your cat resource can be composed of many other resources, like for instance “actions”.
Then, your URI http:///cat/actions could answer to GPPD calls and manage the actions that the cat resource is associated with.
My point is that with some effort, you can model many things as Resources, it’s a matter of finding the right abstractions, I suppose.
(The form validator messed with the fake URL I was using in the example)
I forgot to mention that the “actions” resource would be the list of actions the cat does: walk, talk, whines, etc.