Hacker News Reader

Comment by apphacker | Hacker News Reader

I care about REST because I remember SOAP and I am very happy that REST mostly won that war, at least in the public API space. I suppose there's something to his article about diverging from the idea of resource definitions but I hope that API providers stick to REST as closely as possible and don't do things such as require cookies in their API or have the app manage state some other non-RESTFUL way that isn't simply passing a token as a POST or GET value for example.

View on HN

I never meant to imply that I don't LIKE REST-like APIs on the web. Holy opposite day, Batman, I think they're fabulous! It's really just an exploration of the ways in which the popular definition of REST diverge from the actual definition, and what we can learn from the original definition to make our REST-like APIs all the better.

Yes people have tended to miss out the hypermedia constraint and claim to be REST - partly because everyone's been too excited about using HTTP properly to think about anything else, but also just because there's been a lack of tooling and guidelines for designing media types properly. Most people in the REST community agree on that point and now there are useful approaches and technology emerging - restfulie is a great example of this.

Requiring cookies is exactly the same as requiring specific request headers (like oauth) or even requiring parameters in a GET/POST. Sending updated cookies with an unrelated request isn't that great of thing to be doing, but cookies aren't inherently terrible.

Oauth tokens don't have be in the header and I never put them in the header. Which service requires them to be in the header? Requiring parameters in a get post is the way to manage state in REST, isn't it? How else would you do it? REST does not allow for protected resources? Cookies are terrible because when you are using a programming environment that doesn't have cookie management for free you have to write values in the cookie format from scratch and work with headers when you don't have to do this with RESTlike applications that use OAUTH.

It frustrates me to no end that SOAP is the face of RPC. SOAP is pretty much the worst thing ever, but there are RPC alternatives that don't have SOAP's problems and are less weird (i.e. don't attempt to adhere to an impossible ideal).

I highly recommend checking out JSON-RPC 2.0 or just rolling your own to see how easy it can be. The one I wrote is 200 lines of code and slightly more robust than you actually need to have a working RPC server (I added automatic casting and support for optional parameters with defaults, just for my convenience.)

Reply on news.ycombinator.com