Point taken and I read the quote. But this was also quite adamant that if you didn't do it certain ways it was no longer REST. I think that is a bad way to present simplifying web services in REST and harmful. REST going mainstream was great simply to move away from all POST based SOAPY services.

Do you really believe if you don't use Accept headers as the only means of version that you aren't REST? Is REST a pattern you can follow only to the letter of Roy Fielding's dissertation? If so there might not be ANY REST web services out in the real market that are big. Everyone is just doing RESTish or RESTy instead of certified RESTful.

Also I believe HN is a place where we can discuss articles and pragmatic opinions about it, I don't assume everyone just agrees that this presentation was the one and only way to do REST like the author was stating. I stated my opinion to that. If this is the only way to do REST, simple services then the whole web isn't doing it yet.

This turned out like a rag on REST which it is not. It is a rag on over complicating and ivory tower architecture. REST should be about simplifying web services for consumers as well. When you get to implementing your RESTful service to support all clients, even with the current marke,t you will find it doesn't fit everywhere.

A service should be liberal in what it accepts and conservative in what it sends. The market deems when it is necessary to tighten the standards, right now his interpretation of it is too narrow.

We need a new standard called SIMPLE: RESTish/RPC, HTTP based, simple messaging (JSON/YAML), urls can be abstractions (in fact it is better to hide your models in most cases except for an admin scaffold), consumer aspect based routing (login, signup, myinfo) all the way from front end to service abstraction. Accept and formats can be in headers first and fall back to url based. Kinda like how systems like twitter, facbeook, 37 signals, etc do.