Can somebody explain in one sentence why is REST a good thing? What does it bring to the party? Why is forcing every RPC call that my application makes into CRUDdable objects necessarily a good thing?
Frankly, I can't believe the amount of near-religious attention it's being given. You're taking an obscure aspect of HTTP (already a mind-bendingly terrible protocol in its own right) - verbs - and making it the cornerstone of your application framework.
> [HTTP is] a mind-bendingly terrible protocol in its own right
Could you detail your thoughts on this? The more I work with HTTP, the more I get impressed with how usable it is. Granted, it's not suited for some domains...
Ok, I'm being somewhat unfair. HTTP is an adequate (although overly-complex) protocol for simple document retrieval. It is unfortunate, (in my opinion), that we've used it in a whole ton of ways for which it was never intended.
Have you considered some of the hacks that we have to use to make HTTP do what we want? Comet/longpoll? JSONP? Have you looked at the bajillion different ways in which browsers and proxies fail to implement caching in a consistent manner? How browsers will only allow a limited number of concurrent connections to a particular host? Have you looked at a x-www-form-urlencoded post? Do you think that's a good way to send data around?
Anyway, I'm not really after a big discussion of HTTP's merits - my apologies for excessive opinionation. I am, however, interested in why so many people think REST is a magic bullet.
> Have you considered some of the hacks that we have to use to make HTTP do what we want?
Right, but this sounds like blaming a nail for permanently attaching something when velcro would have been more suitable. Granted, we haven't had many other options, but to me the surprising thing is that HTTP is flexible enough that all of these hacks can be done.
> I am, however, interested in why so many people think REST is a magic bullet.
Well, more accurately, I'm blaming people who think that nails are awesome and the only way to do things - and in fact we should structure all our applications by making use of a relatively obscure aspect of how nails work :)
REST facilitates loose coupling between clients and servers, scalability, caching, retrys etc. REST is a good thing because it provides the right abstractions for some applications.
A slow, unreliable interaction with a remote server is different than an interaction with an in process function call.
If ignoring this complexity is causing no problems then concentrate on what does cause you problems, then just learn enough about REST to recognize a problem in the future.
SOAP v1.0 tunneled everything over POST so you could not cache responses.
A frequent non-restful solution is to return a domain specific id to a client and have the client 'know' that the correct URL is say http://{base}/product/{id}.
The restful solution is to return the URL to the client have them use it what is given rather than construct it. The restful solution allows for many product servers which are independent from the original server. This makes for looser coupling and improved scaling.
REST is essentially what they were thinking, or now think they should have been thinking, when they designed HTTP. So truly honoring the spirit of HTTP gets you close to REST.
But we've known to use GET for operations with no side-effects, and POST for operations that change stuff for many years now, without needing to attach a name to it, throw PUT/DELETE into the mix, or CRUDdifying every operation.
It's the verb part that I really don't get. That, and the general level of excitement surrounding REST. Why are there so damn many articles like this one?
The advantage of the PUT/DELETE verbs is that they are idempotent. If they fail an intermediary or you can safely just apply them again on the same or a different server.
The author of this article has a different understanding of REST than I do. For instance I strongly disagree with this: "One option is not acceptable as a REST response format, except in very specific cases: HTML, or any other format which is meant for human consumption and is not easily processed by clients." I think well marked up HTML is potentially the best response format as long as it is easily understood by clients. And I think this has nothing much to do with REST. Naturally I become motivated to write my own article about REST spelling out how my understanding is is different. Thus the number of articles on REST multiples as a chain reaction until 99.99% of the articles on the internet are about REST. But my 1 year gave me a bad sleep last night dampening the my motivation and saving the world.
Frankly, I can't believe the amount of near-religious attention it's being given. You're taking an obscure aspect of HTTP (already a mind-bendingly terrible protocol in its own right) - verbs - and making it the cornerstone of your application framework.