The point of HATEOAS is to build software whose abstractions are stable across evolving server and client implementations. Software that spans decades, for exa

The point of HATEOAS is to build software whose abstractions are stable across evolving server and client implementations. Software that spans decades, for example, such as HTML, in the face of many different browsers and web frameworks (from CGI through PHP to Ruby/Python/Node). The client (browser, in most cases) is independent from the specific servers, it just knows the media types and link relations. The server has to bind to that media type (i.e. generate HTML). This is a subtle thing for API developers as we mostly just have the HTML web as the big success story for HATEOAS, and haven't done this as much for machine to machine communication... But as an example, the Google crawler is an example of a non-browser that took advantage of the HATEOAS for browsers and built a new application around it that took advantage of the genericness of HTML. i.e. it didn't have to develop an API to each website, it just understood the difference between the links embedded in <A> tag, <IMG> tag and <FORM> tag, and can traverse the links that help it improve its search index. One of the closer attempts to HATEOAS was Facebook and the Open Graph protocol, attempting to describe social data through link relations in a way that's completely independent of specific clients & server implementations. The limiting factor to HATEOAS in practice for API developers is the lack of programming model & tooling for describing & linking API actions together on the Web, which is something actively being experimented over at RESTfest, the W3C REST workshops, etc. There's HAL for example, http://stateless.co/hal_specification.html http://stateless.co/hal_specification.html