Update: Here is a good example of silly REST dogma: http://www.25hoursaday.com/weblog/2008/06/10/TwoCardinalSins... (since a lot of people don't seem to understand that REST isn't the same as HTTP, but more like a religion layered on top of HTTP).
In any situation if you want to refute something a well balanced argument is much more productive, rather than name calling.
The Lenski/Schlafly dialogue is a great example of this (http://www.conservapedia.com/Conservapedia:Lenski_dialog). Lenski gives a compelling argument by refuting Schlafly point by point, not by attacking his religion. While the language is emotive, Lenski backs it with real points, not with the style of rhetoric Schlafly uses.
So far I see very little real discussion in this thread about why RPC is better than REST architectures.
If "religion" here means what it usually means in tech discussions, namely a rigid attachment to an allegedly "right" way of doing things, then I don't think it's unfair at all. I bought the O'Reilly book on REST expecting to learn a lot about web app design, and was really taken aback to find that it was 80% dogma. Having assumed that REST=good, the authors then praise or reject various designs not for what they actually do, but for how closely they adhere to REST. For example, they criticize delicious and flickr for not being proper REST apps, which is pretty amusing.
Incidentally, I don't think the point here is that RPC is better than REST. There are more than two choices. The point is that conforming to REST for its own sake is an example of dogmatic thinking.
I think one of the key points of the book was that Flickr and Delicious could do better with their implementations of a REST API. Just because something is successful doesn't make it optimal.
I absolutely that adhering to something for it's own sake is stupid and dogmatic, I think that suggesting improvements to an implementation based on known benefits of an architecture is perfectly valid.
Another amusing thing about that book is how hard they had to struggle to find real-world examples that passed their REST purity test. If I recall correctly, that's the only reason why Flickr and Delicious even came up.
If anyone here wants a copy, email me. I've still got mine lying around.
Religion is a set of beliefs based on some core principles which cannot be experimentally tested. The beliefs system itself it resilient to refutation, and can "self-heal" if any of its predictions are proven false. While core principles cannot be proven false, they may require some suspension of disbelief from a reasonable person. By their very nature such sets of beliefs are very powerful, and tend to spread and persist. The flip side is that religion has proven to be an inefficient way to generate progress (while, say, science has proven to be efficient).
REST relies on base belief of "resources" and "neglected HTTP verbs", and, by reference, "religion of HTTP." It has its scripture of Roy Fielding dissertation. It's also hard to pin to anything (try to figure out what REST actually is from it's wikipedia article).
A relevant snippet from Richard Feynman was posted here a while back:
Btw, REST certainly does have some useful beliefs in. It is a nice convention for pretty urls, for example. This does not require a suspension of disbelief.
You suggest that based on the Wikipedia article it's hard to figure out what REST actually is.
Wikipedia defines REST as something adhering to some key design principles:
1)Application state and functionality abstracted into resources
2)Uniquely addressable resources using a universal syntax for use in hypermedia links
3)A uniform interface for resources for the transfer of state between the client and the resource.
4)A protocol which is client/server, stateless, cacheable and layered.
That seems like a pretty specific design criteria to me, and not at all dogmatic. Moreover, there have been a number of comparisons of REST Vs. Other architectural styles (see http://www.mnot.net/blog/2005/11/07/REST_vs). And a number of benefits of adhering to REST can be shown.
That said, obviously, like everything else it's not perfect, but it's easy for you to refer to people who advocate the architectural style as a working practice because you clearly don't fully understand it yet given quotes like, It is a nice convention for pretty urls, for example. As URL/URI style has not one iota to do with REST other than resources are uniquely addressable.
You could achieve all of those things w/o using the REST standard, but then it's your standard... and there ought to be at least some reason for rolling your own if one already exists.
HTTP is wonderful, but I've gotten along just fine without ever using PUT or DELETE or other bits of REST dogma, as has the rest of web. Sometimes my urls are actually verbs that I POST arguments to instead of "RESTful" nouns, and it works great.
The point of REST that I thought really stood out in the comments was the one about caching.
If you know that any GET request can be cached subject to whatever is in the expires header or etag, that is hugely useful information when scaling.
REST is not a straight jacket, it's just a simple way of making the /site/url/you/use + the method mean something consistent and logical.
For example, the FriendFeed api includes a method that fetches multiple feeds at once: http://friendfeed.com/api/feed/user?nickname=paul,bret,jim...
Where should one user PUT their updates such that a simple HTTP cache will know to invalidate that GET? It's not possible. The cache must understand the internals of the system in order to do proper invalidation here.
Experience has shown that you cannot make a useful HTTP cache without replicating some custom per-app business logic into it. Paul's example below is a simple case where you HTTP cache would need to support triggers to invalidate one "resource" when another one is updated.
Worse yet, you only get one set of cache headers in your response, and you really need two, one to control the reverse proxy and one for the browser. So any reasonable reverse proxy will (configurably) ignore all caching instructions in the headers.
In general the whole multi-tiered cache framework envisioned in rfc 2616 was a failure. It's just not powerful enough to do anything useful, and it gets in the way.
The point of using common verbs for common actions and sticking to it is that you get to be able to predict the interface.
The overloaded POST vs PUT thing is much less of an issue than other un-RESTful things. The reason not to use RPC style interfaces is that you hide data behind the interface. One of the major wins of RESTful architecture is to make all resources addressable. E.g. I can directly refer to data using a URI.
Flatly: there isn't that much innovation in REST. It's a good idea that can be expressed in a few short sentences. It doesn't deserve books, and it doesn't deserve the priesthood that has grown up around it. When sane ideas start to smell like heavyweight frameworks, they've outlived their usefulness.
REST is just a description for one good way to build certain types of networked applications. I don't think anybody claims that Roy Fielding invented the concept, or that it's the only way to build anything.
If there are people that treat it as a dogma, I don't think you can blame REST; they're just the same loud and obnoxious people that treat everything as a dogma (and usually don't understand it very well).
You can implement HTTP in a more or less RESTful manner. Advocates of REST propose it as the most effective way to provide a Web Service.
Strangely, advocates of SOAP say something similar. This isn't about dogma. If you are insecure about people pointing out that some people claiming to adhere to REST aren't that's your hang up.
I am all about using technology in the most effective manner, this isn't about the religion of one system over another, it's about seeing the benefits of a RESTful architecture. Implementing in a partly RESTful way only gets you part of the benefits.
REST seems to work well for most web applications because they are typically document-oriented. Sites like Youtube, Flickr, Wikipedia, Gmail, Amazon, etc. are dealing with some form of hypermedia documents. It only makes sense to apply CRUD design concepts to documents.
Unfortunately a lot of people have taken REST design concepts too far and try to apply it to everything, which simply won't work. But does this surprise anybody? Its pretty damn hard to saw a 2x4 in half with a hammer.
From a "religious" point-of-view; I do find RESTful websites easier to test & diagnose since problems (application state) can typically be isolated to specific URLs. You gotta love it when you can refer to curl as "the truth"!
As Paul and many others point out, the web has gotten along fine with just the POST and GET verbs; but a good web application is built upon sensible and addressable URLs.
Can you (or anyone) give examples of things on the Web that are not concerned with the transfer and manipulation of resources?
"As Paul and many others point out, the web has gotten along fine with just the POST and GET verbs; but a good web application is built upon sensible and addressable URLs."
URLs do not have to map to the underlying architecture of a site. They are orthogonal if you provide a routing layer, something pretty common and easy to manage in most modern Web frameworks.
I think of REST-style as the read-only calls in any program being hashed to their results (e.g. "mult(5,2)" -> "10"), and used as a cache. If those parameter values are frequent, this can be a huge win. But if always unique, no win at all (minus the hash.put() and hash.get() overhead).
Probably obvious to folks here, but I now realize REST is FP, in its immutableness...
The human readability of REST is very nice (as another commenter said), but that's the specific realization of REST in HTTP - not a necessary to REST-style.
XML can also be used to represent anything, but that does not mean it's a good idea to use it for everything.
$ anImplementation move --from=data/preciousFile.dat --to=data/preciousFile-aug.15.2008.dat
$ mv data/preciousFile.dat data/preciousFile-aug.15.2008.dat
Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.
What I find annoying is people objecting to "POST /actions/subscribe" (with the params in the post body) because it's "non-RESTful" -- the url is a verb and REST demands a noun.
That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.
One that comes to mind is a service with semantics that require a preview step. Sure you can use create/read/update via the REST verbs, but I think a lot of the confusion on this issue comes from wanting to embed the concept of events, so a read may be for the purpose of previewing an item, but it feels more natural to fire a "confirm" event than to do a post with a field called state=cofirmed.
At least that's my personal opinion. I agree that any service can be mapped given sufficient creativity, but it often seems like extra work in the context I described.
Obviously there are cases when there's more than one way to change the state of the object that are only relevant to that object type. In the web world usually the full object state is already on the client so it is not a big deal. You can have your special methods in the client side library and still expose only CRUD methods in the service API.
the URL is part of the UI, both to the user and to api consumers.
If you think of it that way, REST makes a lot of sense. Sure there can be other elegant approaches, but REST is one that has gathered steam b/c it addresses this in a logical, useful way.
This is not an explanation of REST. There are lots of designs that adhere to that general principle and yet don't follow REST at all.