RESTful APIs R.I.P.(mmikowski.github.io)

mmikowski.github.io

http://mmikowski.github.io/the_lie/

4 comments

So the author proposes to replace REST with "JSON-pure APIs": Just stuff all of your data (errors, warnings, data, domain-specific stuff; he really does not propose any structure) into JSON, and then send and receive that via anything.

With this, we would lose the discoverability of a good REST API (see https://en.wikipedia.org/wiki/HATEOAS ), which would be a huge price to pay.

Other than that, this reminds me a bit of:

"Hey man, this relational stuff is really hard! There must be a better way..."

"I know a better way! Let's rather just stick all of our data into these JSON objects..."

Avernar11 anni fa

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.

geonik11 anni fa

When it comes to APIs, every now and then someone say "X is dead, Y is the future".

APIs are not a one-size-fits-all problem, and while general trends and paradigms are a nice thing to have, developers should not be restricted by whatever is the hottest buzzword today.

A nice and clean API will always be pleasant to use, and this has nothing to do with RESTful awesomeness or SOAP verbosity.

innerspirit11 anni fa

"...it has served us well for two decades. [...] is probably one of the worst ideas ever widely adopted in web software"

platinumdragon11 anni fa