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