

RESTful APIs R.I.P. - jsnathan
http://mmikowski.github.io/the_lie/

======
cpbotha
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](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..."

~~~
Avernar
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.

------
geonik
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.

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

