I think calling REST a religion is pretty unfair, and an emotive response rather than being an argument against it.
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.
Personally I found the ORA REST book did a good job of explaining some of the key problems that using HTTP RESTfully solves and the benefits that brings.
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.
But their suggestions had nothing to do with making Flickr and Delicious better - only more conformant to REST. Which was just my point: you have to assume that "REST = good" in order to call that "better". Personally, I'd rather learn about web app design by studying Flickr, Delicious, and Gmail than by making an assumption like that and then limiting my thinking to what it allows.
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.
I disagree. Dogma/religion fits REST very well. It's also a very useful way to describe it, and the concept of religion is very rich and carries a lot of information in it.
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).
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 describe religion as a set of beliefs based on some core principles which cannot be experimentally tested.
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.
did you read the comments on his blog post? There are some excellent points made.
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.
Yeah, the comments are crazy and seem to completely miss the point.
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.
If your application is a simple key/value store, then scaling won't be a problem. If it's something more complex, then such simplistic caching models won't work.
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.
Right, that means that you are doing your own cache invalidation (by changing the etag or last modified time), not relying on some magic proxy which watches for PUT and DELETE. That also means that you can use normal HTTP and ignore this REST nonsense.
Fair enough, but the thing I like about REST is the consistent API and (ideally) proper handle of request types via mime type information in the header.
Caching is a poor argument for REST, as is it's provably false.
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.
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).