Comment by wanderr | Hacker News Reader

Comment by wanderr | Hacker News Reader

REST has always felt a little bit dirty to me; an improper commingling of what should be two different layers. To me, using aspects of the HTTP protocol to have meaning for a higher level service is a bit like using aspects of the TCP protocol as part of the HTTP definition, where in a more ideal setup they should be independent, but layered on top of one another. Almost all of the REST mistakes mentioned in this article are due to the unholy matrimony of the two layers, and the misunderstandings and abuses that arise from that. Additionally, using HTTP error codes can break compatibility for anything running in a browser plugin (i.e. Flash) because the browser eats the error code and does not pass it on to the plugin. Needless to say, I'm a big fan of RPC which runs over HTTP POST normally but isn't married to the underlying protocol. I think SOAP gives RPC a bad name (I certainly hate the crap out of it) and doesn't properly separate the protocols either, using HTTP codes to indicate errors and such.

I think you might be wrong about the 'underlying protocol'. HTTP is an application layer protocol. If something feels dirty it is to put another protocol on top of it especially if it doesn't add value.

With REST, you are not adding more special meaning than the HTTP methods. Using those methods according to the spec is all there is to it. If that's enough to do your business, why add more to it? Things should be simple as much as possible.

Simplicity is good, but so is flexibility and compatibility. As I mentioned, parts of REST aren't good enough; anything that doesn't have access to http status codes won't be fully compatible. A decent RPC protocol like JSON-RPC is both flexible and simple. An added bonus to not marrying your protocol to http is that your API will work seamlessly over other protocols should the need arise. I have an API that was originally intended for web clients, but later the need arose for some internal tools to be able to call the same methods remotely and asyncronously. Instead of going over http, the jobs are submitted to gearman in JSON-RPC format and everything works without having to modify the server or unnecessarily and inefficiently route the calls externally through apache.

I used to argue in favor of json-rpc as well, but I have to say that I have allied with the dark side now. if for no other reason than caching, with REST you have fine control over what addressable resources get cached and which do not. This is huge for performance in some systems. I have found once you use REST semantics in earnest to build an application, it is hard to levy argument against it. So much of the webs infrastructure starts to work with you and not against you once you start to use it.

It's possible my perspective is skewed. I write APIs for stateful applications, so clients don't ask for the same information over and over, reducing the need/utility of browser caching. I can see how REST would help solve the caching problem.

I agree with that. But here you aren't talking about HTTP you are talking about RPC. You could have gone with RPC directly from the very beginning. Typically, you put that on top of HTTP to avoid firewalls, etc.

I said simple as possible, but the real world is always complex and one day you may have to use something other than JSON-RPC in which case someone will have to create an adapter or an abstraction. Thankfully this is easy to do in software even if it sometimes looks nightmarish.

Reply on news.ycombinator.com