I author REST APIs and try to do them properly, with mediatypes, link relations, and all the good hypermedia stuff most people avoid. Nonetheless, the author's post reflects the sort of rant I've had to coworkers at the watercooler, or anyone who'd listen.
The author nicely preempts the debate about HATEOAS and "most RESTful APIs aren't REST" and shows that the debate is part of the problem. It is. It's not a spec but an architectural style, and people are bad at design (and quite honestly, they have better things to do with their time), so broad-stroke ideas about how to lay out your system aren't as useful as a framework or codegen. So the least-effort solution wins, where you half-ass implement first three three characteristics of REST-as-seemingly-observed-in-the-wild (HTTP, JSON, templated URLs), and call it a day. If it's good enough for Stripe and Twitter, it's good enough for you.
No wonder we're in this boat; one upon a time REST was just architectural and intellectual wankery, specified in an obtuse and hard-to-read thesis by a guy who's smarter than most of us combined. It sat unknown for years, until AJAX became all the rage, and people began making API calls from jQuery to load-and-splice parts of a page for rich interactivity. Here, a public, HTTP endpoint that served easily-parseable JSON made sense. Some prominent companies released public APIs in this style, and then the blogspam began.
Within a short amount of time, REST and "RESTful" was cool and forward-looking, and SOAP was old and crufty, and any kind of ad-hoc RPC was bad. Implementing a REST API wasn't solely about usability, but also signalling that your company was forward-looking too, rationality be damned, which is why most implementations cargo-cult look the same: HTTP, schemaless JSON, templated URLs. Endless debates about HATEOAS begin, and come to an unsatisfying conclusion, because real developers' concerns about architectural purity are dwarfed by their desire to build a mostly-working API that looks recognizable to the public, and move on.
Serious players looking for reliable internal RPC develop stuff like Thrift and gRPC, which are thoughtful reimplementations of the ideas behind 80s and 90s RPC, but with the added advantage of coming from a single vendor and not committee hell. Meanwhile, Facebook also reinvents SQL in JSON and gives it to the client, what could go wrong?
Maybe the reason "REST" won is because it was easy to glean and misunderstand well enough to put out something simple and good enough. This dominance of the low-end is going to be hard to undo.
As I mentioned elsewhere in the thread, there are two posts on the intercooler site that specifically addresses this issue that I found very compelling:
The difference is that a real HATEOAS API provides clients with context through the payload for all service interactions. HTTP becomes just the transport layer. Roy Fielding never wanted to point to anything else. He was inspired by how HTML enabled human-to-service interaction through a Browser (the client) and formulated an architectural style for human/machine-to-service interaction. The emphasis must be on how we design formats. Communicating the state is just freestyle, HTTP being the prominent one.
Thank you. This is one that I've been puzzling over for years. If anyone has a straightforward answer, and can provide example REST responses with and without "HATEOAS", I'd really appreciate it.
See the 'Richardson Maturity Model' levels [1], and contrast level 2 with 3. Level 3, satisfying the HATEOAS constraint, has hyperlinks leading to other resources, and the relationship between the origin and destination resource is qualified (with link relations [2]).
Essentially, everything is a graph, resources are the nodes, and the labels on edges are the relations, also serving as an inventory of state transitions.
The "HATEOAS debate" is the trope that says people will inevitably debate whether a particular API that claims to adhere to REST does in fact adhere to REST, because many APIs that namedrop REST don't satisfy the HATEOAS constraint. This is rarely a practical debate, but the fact that it keeps coming up -- and people take the time to explain -- is part of the problem with REST. This was the author's point.
I think the problem I have a hard time with HATEOAS is that I really can't see what difference it makes to the API. I mean I get that it's always better to return a URI rather than simply an ID. But the link relations feel like they are from a time when we all thought the semantic web (RDF and OWL) was going to be a very big deal.
The author nicely preempts the debate about HATEOAS and "most RESTful APIs aren't REST" and shows that the debate is part of the problem. It is. It's not a spec but an architectural style, and people are bad at design (and quite honestly, they have better things to do with their time), so broad-stroke ideas about how to lay out your system aren't as useful as a framework or codegen. So the least-effort solution wins, where you half-ass implement first three three characteristics of REST-as-seemingly-observed-in-the-wild (HTTP, JSON, templated URLs), and call it a day. If it's good enough for Stripe and Twitter, it's good enough for you.
No wonder we're in this boat; one upon a time REST was just architectural and intellectual wankery, specified in an obtuse and hard-to-read thesis by a guy who's smarter than most of us combined. It sat unknown for years, until AJAX became all the rage, and people began making API calls from jQuery to load-and-splice parts of a page for rich interactivity. Here, a public, HTTP endpoint that served easily-parseable JSON made sense. Some prominent companies released public APIs in this style, and then the blogspam began.
Within a short amount of time, REST and "RESTful" was cool and forward-looking, and SOAP was old and crufty, and any kind of ad-hoc RPC was bad. Implementing a REST API wasn't solely about usability, but also signalling that your company was forward-looking too, rationality be damned, which is why most implementations cargo-cult look the same: HTTP, schemaless JSON, templated URLs. Endless debates about HATEOAS begin, and come to an unsatisfying conclusion, because real developers' concerns about architectural purity are dwarfed by their desire to build a mostly-working API that looks recognizable to the public, and move on.
Serious players looking for reliable internal RPC develop stuff like Thrift and gRPC, which are thoughtful reimplementations of the ideas behind 80s and 90s RPC, but with the added advantage of coming from a single vendor and not committee hell. Meanwhile, Facebook also reinvents SQL in JSON and gives it to the client, what could go wrong?
Maybe the reason "REST" won is because it was easy to glean and misunderstand well enough to put out something simple and good enough. This dominance of the low-end is going to be hard to undo.