The point here seems to essentially be "we have no standardisation" and therefore there's no point doing HATEOAS.
Surely it's just a catch 22? We need more HATEOAS (because almost no one is doing it right now) before we will get the standardisation, and we need the standardisation before anyone will see the advantages clearly enough to invest time in HATEOAS.
I think the best approach is to build up the tooling for HATEOAS, get all those 'RESTful web frameworks' providing support for it, and using it within individual services to enable more fluid APIs. By this I mean APIs that can be changed to some degree to iterate, add features, or react to heavy loads on particular endpoints, while clients don't need to change each time, and can instead adapt automatically to different data being returned.
Google already do this with their private APIs for mobile applications, and that's where I think we will see growth of features that make sense to implement now.
The author seems to be raging based on the premise that HATEOAS means "self-documenting". But HATEOAS doesn't mean that, and has never meant that; it means that the API should be documented primarily (ideally fully) by documenting the resource types and relation types, rather than the resource locations and meanings of verbs with regard to specific locations [1] (which, in a system using HATEOAS, are communicated in resources themselves, so that if you have access to the location of a "root resource" that provides an entry point, you don't need any documentation of other locations.)
This seems to be entirely misdirected rage based on a fundamental misunderstanding of HATEOAS.
A REST API should spend almost all of its descriptive
effort in defining the media type(s) used for
representing resources and driving application state, or
in defining extended relation names and/or hypertext-
enabled mark-up for existing standard media types.
2 comments
[ 4.3 ms ] story [ 30.1 ms ] threadSurely it's just a catch 22? We need more HATEOAS (because almost no one is doing it right now) before we will get the standardisation, and we need the standardisation before anyone will see the advantages clearly enough to invest time in HATEOAS.
I think the best approach is to build up the tooling for HATEOAS, get all those 'RESTful web frameworks' providing support for it, and using it within individual services to enable more fluid APIs. By this I mean APIs that can be changed to some degree to iterate, add features, or react to heavy loads on particular endpoints, while clients don't need to change each time, and can instead adapt automatically to different data being returned.
Google already do this with their private APIs for mobile applications, and that's where I think we will see growth of features that make sense to implement now.
This seems to be entirely misdirected rage based on a fundamental misunderstanding of HATEOAS.
[1] Per: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...