8 ms·
REST, I just don't get it
- paul 18y agoExactly right. The dogma that develops around these kinds of things is so weird. Update: Here is a good example of silly REST dogma: http://www.25hoursaday.com/weblog/2008/06/10/TwoCardinalSinsOfRESTAPIDesignLessonsYouCanLearnFromTheNewsGatorRESTAPI.aspx 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).
- gunderson 18y agodid 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.
- paul 18y agoYeah, 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.
- gunderson 18y agoRight 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.
- paul 18y agoIf 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&format=atom 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.
- gunderson 18y agonot 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.
- paul 18y agoRight, 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.
- gunderson 18y agoFair 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.
- deleted 18y ago[deleted]
- gleb 18y agoCaching 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.
- sh1mmer 18y agoI 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 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.
- gruseom 18y agoI 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.
- sh1mmer 18y agoPersonally 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.
- 18y ago
- 13ren 18y agoREST'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.
- richtaur 18y agoNot understanding something isn't a reason it's not good...
- gcv 18y agoI 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."
- gaika 18y agoWhen 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.
- tlrobinson 18y agoAssuming 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.
- delano 18y agoIt'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 or $ mv data/preciousFile.dat data/preciousFile-aug.15.2008.dat
- hassy 18y ago> 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.
- gunderson 18y agothe 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.
- gruseom 18y agothe 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.
- sh1mmer 18y agoHTTP 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.
- ajross 18y agoExcept 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.
- sh1mmer 18y agoI 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.
- bct 18y ago> 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).
- bct 18y agoI see that we're deep into the backlash phase of the hype cycle.
- bradgessler 18y agoThe 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.
- jamesbritt 18y ago"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.
- bitdiddle 18y agoI thought REST was just a synonym for CDR :)