[wyuenho]

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems:

1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means:

    <form action="/some/noun" method="POST">

If you are religiously RESTful, you probably think this is fine. But I'm a religious English reader. When I see the word "action", I think of a verb, not a noun. When I see the word "method", I think of "how", not "what". So when I look at the HTTP spec, all the HTTP "verb"s look to me like how-I-should-do-something, instead of what-to-do, and the resources (URLs) look to me like the what-to-do, instead of what-they-represent.

Small semantics issues I suppose, but here's another one:

2. HTTP is not a programming language, and yet it demands a (very) finite set of actions and an infinite set of objects to model the real world, where there are an infinite number of actions and objects. What I mean is, in Java or whatever OOP language, I can define classes to model objects and define methods in classes to model actions on objects, but I'm not sure if I can do it pragmatically in HTTP without getting yelled at.

3. HTTP statuses. Almost the same problem as the above. I have many different kinds of statuses, not all of them fit in the finite set of HTTP statuses, and they don't always provide the granularity I want. Can I return a non-standard status number? How would the clients behave? I have no idea.

4. Being RESTful means not being stateful. But you see, there's this thing called session and login cookies and many other tracking cookies that I have to take care of. Again, I don't just write APIs, I write Web apps. I would like to not do multiple handshake requests just because a paper says I should. I would also like to not get yelled at when I decide not to.

5. HTTP is RESTful, thus HTTP is REST. Please don't tell me HTTP is the best we can do. Can I have something more minimalist, extensible and powerful enough to model the real world?

-- A troubled Web dev.

[balakk]

I think you're mixing up multiple things.

- HTTP is a protocol.

- HTML is a markup lanaguage.

- REST is an architectural model for building web services.

They are all different.

> HTTP is not a programming language.. > HTTP statuses > REST is stateless

HTTP is a protocol. A protocol by definition allows certain constructs and prohibits others. There are books available for modeling real-world problems with REST, such as RESTful web services cookbook. I'd suggest going through them, before declaring REST is impractical.

>I'm not sure if I can do it pragmatically in HTTP without getting yelled at

You can certainly use HTTP as you like it, just please don't call it RESTful unless it actually is. A lot of web APIs are not RESTful, nothing wrong with that.

> don't tell me HTTP is the best we can do..

Unfortunately it is for now. Everybody is free to invent their own protocol, write production quality servers to implement it, and get everybody else to adopt it.

[icebraining]

1) HTML isn't English, it just has some similar sounding tokens. You can't assume the semantics are the same.

2) Well, there's HTTP and there's REST, they're related but no the same. HTTP is a full protocol, completely defined; you can't add more verbs, period.

REST is an architectural style. It has a series of constraints, and it tells you that if your system architecture complies to them, it'll have some useful properties, like low coupling and such. HTTP is just an example of a RESTful architecture.

Now, if you're designing an architecture and you want to follow REST, you can choose the verbs you want, but these should be generalist and not tied to specific names. This provides an Uniform Interface, which simplifies and decouples the the architecture.

3) See above. HTTP statuses are fixed, you can't return other stuff. If you're designing your own architecture, you can use whatever you want. Hell, you can return different pictures of kitties for each status if you want to.

4) As the Zen of Python states, practicality beats purity. But you should be aware that by adding state to the connection, you'll lose some advantages. Let's say the user is performing a multiple step action, and the server he's using breaks. If the server was holding the state, now the user has lost all the work and he'll be pissed at you. If on the other hand, the state was saved by either the client, or more "RESTfully", by the mere fact that he was on a specific URL, than any other server can pick up where the other left without annoying the user.

5) Sure. We just need to rewrite all the browsers and servers worldwide, including a bunch of embedded ones that can't be reflashed. It's possible...

[dedward]

to #4 - that's only true if you designed your app to rely on a single server and have no fault tolerance or distributed sessions. Argh.

[JanezStupar]

The original stateless way has fault and partition tolerance baked right in. By breaking this convention you open yourself to a world of hurt, no matter how many band aid concepts you patch over it.

If you had ever designed or worked on a distributed system that needed to scale you wouldn't talk about adding servers and sharing state (distributed anything).

Sure distributing state is a fail-safe strategy - but not a scalable or performant one.

[noduerme]

It's actually kind of lame that this pompous flamebait makes it to the top of HN, and then he concludes his post saying he doesn't take comments on his blog. excusez-moi, what is he the New Yorker? I'd prefer to address his pomposity on his own turf rather than here, so all I'm going to say is this has all been said before, and it's a bitter irony to spend time talking about flogging dead horses while debating the semantics of a meaningless buzzword with nobody but yourself.

[mattgreenrocks]

We're getting off-topic, but I don't blame him. A lot of comments are just really bad, and he doesn't want to deal with them.