
REST, I just don't get it - llimllib
http://damienkatz.net/2008/08/rest-i-just-dont-get-it.html
======
paul
Exactly 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/TwoCardinalSins...](http://www.25hoursaday.com/weblog/2008/06/10/TwoCardinalSinsOfRESTAPIDesignLessonsYouCanLearnFromTheNewsGatorRESTAPI.aspx)
(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).

~~~
sh1mmer
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.

~~~
gruseom
_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.

~~~
sh1mmer
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.

~~~
marijn
Which book are you referring to? Googling brought me right back to this very
comment.

~~~
gruseom
I'm talking about <http://oreilly.com/catalog/9780596529260/>.

If anyone here wants a copy, email me. I've still got mine lying around.

------
sh1mmer
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.

~~~
ajross
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.

~~~
bct
> 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).

------
bradgessler
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.

~~~
jamesbritt
"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.

------
13ren
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.

------
hassy
> 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.

------
delano
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
    

or

    
    
      $ mv data/preciousFile.dat data/preciousFile-aug.15.2008.dat

~~~
davidw
Make people use the first one instead of the second one, for the sake of
"clarity", and they'll be banging at your door with torches and pitchforks in
no time flat.

~~~
delano
That's my point, ironically.

------
bct
I see that we're deep into the backlash phase of the hype cycle.

------
gaika
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.

~~~
tlrobinson
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.

~~~
gaika
Do you have an example of an online service that doesn't fit into RESTful
model?

~~~
paul
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!

~~~
gunderson
And your point?

~~~
paul
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".

~~~
gaika
Sorry, but I asked about a service that doesn't FIT the RESTful model.

~~~
paul
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.

~~~
gaika
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.

~~~
paul
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.

~~~
bct
REST doesn't _demand_ a noun. If they all have the same code backing them,
there's no functional difference between:

    
    
        POST /actions/subscribe
    

and

    
    
        POST /subscriptions
    

and

    
    
        POST /abcdef1234567890
    

The shape of a URL has nothing to do with REST. However, if a lot of your URLs
contain verbs it _suggests_ that you aren't doing REST. It's a design odor.

------
gcv
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."

------
gunderson
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.

~~~
gruseom
_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.

------
bitdiddle
I thought REST was just a synonym for CDR :)

------
richtaur
Not understanding something isn't a reason it's not good...

