REST, I just don't get it(damienkatz.net)
damienkatz.net
REST, I just don't get it
http://damienkatz.net/2008/08/rest-i-just-dont-get-it.html
51 comments
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.
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.
I think calling REST a religion is pretty unfair
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.
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.
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.
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.
Which book are you referring to? Googling brought me right back to this very comment.
I'm talking about http://oreilly.com/catalog/9780596529260/.
If anyone here wants a copy, email me. I've still got mine lying around.
If anyone here wants a copy, email me. I've still got mine lying around.
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).
A relevant snippet from Richard Feynman was posted here a while back: http://www.collectedthoughts.com/quote.aspx?id=11302
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.
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: http://www.collectedthoughts.com/quote.aspx?id=11302
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.
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.
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.
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.
Right it may work for you, which is fine.
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.
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.
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.
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.
not really, the system would only need to keep track of the last updated time of each record and when aggregating them, set the proper etag.
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.
[deleted]
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.
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.
HTTP is an implementation of REST. REST is an architectural style defined by Roy Fielding in his PhD thesis.
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.
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.
Except that the problem is that precisely none of those features were invented by the REST people. This is the way sane network applications have worked since the beginning of time. What REST introduced is a dogma that said not only "this is good" (something no one agrees with) but "you must do it precisely this way", which is just ridiculous.
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.
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.
> What REST introduced is a dogma that said not only "this is good" (something no one agrees with) but "you must do it precisely this way"
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).
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).
I disagree. REST created a framework, one implementation of which is HTTP.
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.
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.
The comments about REST being religious seem to miss the point. It seems Damien is simply saying, "REST isn't the answer for EVERYTHING". That's a pretty straight-forward and safe statement to make.
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.
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.
"REST seems to work well for most web applications because they are typically document-oriented. "
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.
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.
REST's big win, as a commenter said, is caching.
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.
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.
> But what is the big advantage of making all your calls into GET PUT and DELETE? If POST can handle everything you need, then what's the problem?
XML can also be used to represent anything, but that does not mean it's a good idea to use it for everything.
XML can also be used to represent anything, but that does not mean it's a good idea to use it for everything.
It's still REST even when you don't use PUT, HEAD, or DELETE. Regardless, verbs are important. Consider the command-line. Which is more clear:
$ anImplementation move --from=data/preciousFile.dat --to=data/preciousFile-aug.15.2008.dat
$ mv data/preciousFile.dat data/preciousFile-aug.15.2008.datI see that we're deep into the backlash phase of the hype cycle.
When your API is RESTful you have a lot less explaining to do in your documentation. It totally makes sense for services to conform to the same pattern.
Assuming the service maps cleanly to the HTTP verbs, which if it does he says by all means use a RESTful interface, but if not, don't be afraid to make it non-RESTful.
Do you have an example of an online service that doesn't fit into RESTful model?
Nearly all of them? Run your packet sniffer on Gmail for example -- I guarantee that send isn't implemented with a PUT to noun url!
And your point?
He asked for an example of a web service that doesn't follow the RESTful model. I replied to his request. My point is that almost no web service is truly "RESTful".
Sorry, but I asked about a service that doesn't FIT the RESTful model.
Well, I guess it depends how you define "FIT". It's possible to shoehorn just about any service into just about any model, but that doesn't make it a good idea. For example, sending email by doing a PUT to some newly created URL is silly. There's a reason that the english language has more than 5 verbs.
Right, closer analogy would be object oriented programming, where some methods are standard (constructor->post, destructor->delete, copy->get, assignment->put) and some are totally type specific. The point of REST is that these type specific methods do not have to pollute your core / transport and can happily reside in your client libraries.
Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.
Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.
I think perhaps we're talking about a different aspect of REST.
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.
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.
REST doesn't demand a noun. If they all have the same code backing them, there's no functional difference between:
POST /actions/subscribe
POST /subscriptions
POST /abcdef1234567890
What's wrong with creating a subscription object and letting people manipulate it the usual REST way via /subscription/<id>?
That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.
That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.
[deleted]
This is a fun question. I don't, but I'm curious what you think are the most persuasive examples of services that don't fit.
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.
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.
You can think of RESTful approach as an extreme case of object oriented programming when your methods are limited to CRUD.
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.
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.
You have more explaining to do. Most api users have no idea WTF DELETE and PUT are.
I guess I always understood the principles behind full-on REST using all the neglected HTTP methods as a way of enforcing clean API design. Good programmers can, of course, just use POST methods for an API, and not cause grief. Others might need some nudging in the right direction: "no, that's closest to a deletion so use DELETE; and that's closer to a store so use PUT."
the simplest explanation of REST:
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.
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.
the URL is part of the UI, both to the user and to api consumers
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.
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.
I thought REST was just a synonym for CDR :)
Not understanding something isn't a reason it's not good...
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).