Why are people so adamant that they absolutely must call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!
HATEOAS is for snake oil sellers and their religious followers, who want to feel superior.
There are gains to be made from certain design decisions and HATEOAS in my experience with multiple front end teams and multiple back end teams working in HATEOAS-land is that the HATEOAS systems were able to address ongoing systems evolution in ways that when complexity did come up, it was easier to address and manage.
I'm not here to proposition it as a silver bullet, or have quantitative data to substantiate it, but in my experience the ease of ongoing system architectural evolution in both client and server realms made up for the difference in tension between the two camps.
One example of a tension in HATEOAS is the complaint from clients that they can't hardcode links like they did before. One of the points, obviously, of HATEOAS is the ability to represent state using hypermedia[links]. One terrible thing the backend could do is make clients traverse multiple resources to get a url to perform an action elsewhere[1].
Rather than saying "tough luck, deal with it," communication workflows and architecture was adjusted so that for most workflows, the required urls were made available as a natural part of accessing resources needed to accomplish the workflow.
Does this require some work on the client to extract the link and use it for the next step in the workflow? yes. Do the other benefits make up for it? It did in my org. It might in yours. Part of being a good architect is making that decision correctly more often than not.
1. I'm being a bit loose with terminology, but I hope it helps rather than detracts from understanding.
> I should stress that the RMM, while a good way to think about what the elements of REST, is not a definition of levels of REST itself. Roy Fielding has made it clear that level 3 RMM is a pre-condition of REST.
It's good for marketing I guess? A while ago REST took on connotations of "simple" and "clean", mostly in comparison to SOAP. So people will probably think more highly of your API if you call it REST.
So, yeah, REST means whatever people use it for, that is 'HTTP services with JSON payload'. That's the actually valuable part of it anyway, the meaning that was documented after everybody started using it wrong is a synonym for the web, and we already have a name for it.
REST isn’t a standard, it’s an architectural style. And I’m not sure how you can say that the author chose not to document its meaning when the name “REST” originated with the author’s PhD dissertation.
One big difference is that WWW clients are browsers, which you don't develop yourself. API clients are typically developed by the same team that builds the API.
Losing interoperability is detrimental for WWW (browser wars), but turns out when you are the consumer of your own API, interoperability is not important at all.
What would you call it though? If the only thing we call REST is what's called a "level 3 REST" API in this article, then virtually nothing would be called REST.