

REST Questions - chrisbroadfoot
http://www.tbray.org/ongoing/When/200x/2008/08/18/On-REST

======
ajross
Amen. I can't think of anything to add to this article other than "thank
goodness someone sane is saying this".

It's not that REST is a bad architecture, actually. It's that the things that
make REST a good architecture are things that are done elsewhere on a regular
basis without the kind of praise or priesthood that you get when you give it a
hard-to-grok ("representational state transfer!?") acronym for a name.

What we're seeing with REST is what we saw with Design Patterns in the 90's. A
bunch of very simple, very sane ideas turned into a parody of what they were
supposed to have been. DP was a cookbook for how to solve common design
problems, but what we ended up with (c.f. much of the Java libraries, swing
especially) were kitchens designed so closely to that model that they could
_only_ produce the recipes in the cookbook.

~~~
bct
What's hard to grok about the name? It's an architectural style that's based
entirely around transferring representations of resource state between client
and server.

Names are useful. If the name is misused or used to justify silly things, I
don't think you should blame the namer.

~~~
ajross
How is a "representation of resource state" any different than a "thing"
though? _Every_ data structure is a "representation of state". There's almost
no meaning there. It's just filler. Other competitors don't have this problem:
"remote procedure call" directly evokes what's happening (a synchronous call
and response); likewise what an ORB does is, in fact, brokerage of object
requests. All you get from REST is that you're sending some "stuff" from one
place to another, and a vague promise that it's "state" (data) instead of
behavior.

If REST really wanted to pick a good name, wouldn't it involve the notion of
"stateless resources as URLs" somewhere? They're kinda the central point.

Look: the point here isn't to smack about REST's name. I don't care what you
call it, that's not the problem. The problem is that a lot of REST proponents
actually think that REST invented a lot of stuff (like, heh, representing
state) that are just pre-existing good ideas to which it gave a name.

~~~
bct
I think this is largely a problem of jargon. "Object request broker" may have
a useful meaning to you, but I've only got a very vague idea of what it might
be. (I could look it up, but what I've learned over the last two days is that
it's much easier to say that it's a dumb idea, its proponents treat it as
dogma, and besides everybody was already using its useful ideas anyhow.)

I get Remote Procedure Call, but I don't see how "a synchronous call and
response" comes from the name; stripped of its nuances, all the name means is
"doing something somewhere else".

Similarly, "transferring a representation of a resource's state" is much more
precise than "sending some "stuff" from one place to another", but only if
you're familiar with what I mean by "transfer" and "a resource's state".

> The problem is that a lot of REST proponents actually think that REST
> invented a lot of stuff

A lot of people think a lot of stupid things. Why is that notable?

~~~
dfox
The notable thing is that "REST" seems to be nothing more than buzzword-
compatible name for HTTP.

~~~
bct
So a stateful RPC system is RESTful, as long as it uses HTTP? Surely that's
not what you mean.

~~~
dfox
In my opinion, when you use HTTP as a transport for some ugliness, you should
not call the resulting contraption HTTP.

For some reason recently we have this technologies like AJAX and REST, that
does not mean anything concrete, just "we are using this to achieve that and
need some name for managers".

And that is what I'm trying to say: Why in the world do we need to label some
more or less trivial idea with some cute initialism?

~~~
bct
A lot of people don't get the distinction between HTTP and "HTTP as a
transport for some ugliness".

The cute initialism isn't the point. The paper that coined the initialism (and
describes why HTTP was designed the way it was and what you'll lose if you use
it as a transport for some ugliness) is.

~~~
dfox
But reality is that the paper is just analysis of how Web/HTTP works and or
how it is supposed to work, not introduction of some new approach.

~~~
bct
Of course, I don't think that anybody credible disagrees with that.

That doesn't mean that REST "does not mean anything concrete", though.

