I agree with the author. I came to the same conclusion way back. Shoehorning commands and errors onto HTTP request methods and response codes was frustrating.

I agree with the author. I came to the same conclusion way back. Shoehorning commands and errors onto HTTP request methods and response codes was frustrating. As the author wrote, they're not rich enough to map on to. For example, if an error occurs what do I return? 400 Bad Request? What does that mean to the client who needs to show something to the user? Have to stick some details in the JSON response like an error field with the detailed message. So why not just check if there is an error field in the JSON response and make 200 OK mean that the HTTP request made it to the server. Now the client is simpler as the error callback is just for HTTP transmission errors (host not found, transmission errors, etc) and the success callback is just for communication with my back end code. The HATEOAS just combines the documentation with the protocol. No thank you. I'd rather have a good API document to work from and a fixed API rather than trying to dynamically figure out what's going on. Seems HATEOAS is more suited for interaction with a human rather than a machine to machine protocol. It's ironic that you used the NOSQL vs RDBMS debate as an example to prove your point. HTTP is a transport protocol. While it has some support for being an API layer it is way inadequate for that purpose. Expanding it is just not feasible as most servers and clients don't even support all of the existing options. So just use what's best designed for the task. HTTP for transport and JSON for data. Makes things a lot simpler.