Hacker News new | past | comments | ask | show | jobs | submit login

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?


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


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


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.


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.


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

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




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: