

Why I Hate HATEOAS - brown9-2
http://jeffknupp.com/blog/2014/06/03/why-i-hate-hateoas/

======
dragonwriter
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.

[1] Per: [http://roy.gbiv.com/untangled/2008/rest-apis-must-be-
hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-
driven)

    
    
      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.

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

