4 ms·

IMHO HATEOAS seems like a solution looking for a problem. I've built and consumed lots of APIs and I've never encountered a solution where I wished that a mecha

by kt9 14y ago

IMHO HATEOAS seems like a solution looking for a problem. I've built and consumed lots of APIs and I've never encountered a solution where I wished that a mechanism existed to discover the next step automatically from the first endpoint. Using HTTP verbs and resources is super useful and has caught on because its super simple. HATEOAS seems like a whole bunch of complexity to me that doesn't seem to add much value. Maybe I'm wrong and just need to better understand the use case and value proposition.

bpatrianakos 14y ago
I don't think you're wrong. I can agree completely. But at the same time maybe we feel this way because we're not used to working with HATEOAS APIs. I personally haven't ever wished I could discover the next step while using an API either but maybe if those APIs were more common we'd be wondering how we ever lived without them.
- icebraining 14y ago
  How did you find out the reply page to post that message? HATEOAS, like all of REST, is modeled after the biggest API ecosystem we have: the (HTML) web.
parasubvert 14y ago
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
dscrd 14y ago
I sort of agree with you, HATEOAS seems to be the least useful thing of the whole bunch for system<->system APIs. However, when there's a human involved (like, when coding against that API), it can be quite nice.
alanctgardner2 14y ago
LinkedIn, Google and Atlassian JIRA's REST APIs all correctly implement HATEOAS. It helps to make your application less brittle when calling a third party API: if they suddenly change how a particular URL is formed, you already know from parsing the HATEOAS. The kind of daft thing is that they provide a separate reference with all those links anyways; they have to uprev the API (and docs) if they actually want to make one of these changes. So, they're doing the right thing, but taking all the good out of it.
specialist 14y ago
I'm on the otherside of the fence. HATEOAS just seems obvious, as in why would someone do it any other way. I recently wrote a client to spider legislation data published as WSDL. Were the reply/result documents HATEOAS, the spider would be trivial. But I have to basically do ETL between every reply and the next request (walking the children of a parent). At the day job, some of the RESTful APIs (written by others) are mostly HATEOAS. It's a pretty big win. Clients are easier, inspection and verification is easier, non programmers almost kinda grok them, etc.

by kt9 14y ago

bpatrianakos 14y ago

I don't think you're wrong. I can agree completely. But at the same time maybe we feel this way because we're not used to working with HATEOAS APIs. I personally haven't ever wished I could discover the next step while using an API either but maybe if those APIs were more common we'd be wondering how we ever lived without them.

icebraining 14y ago
How did you find out the reply page to post that message? HATEOAS, like all of REST, is modeled after the biggest API ecosystem we have: the (HTML) web.

parasubvert 14y ago

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

dscrd 14y ago

I sort of agree with you, HATEOAS seems to be the least useful thing of the whole bunch for system<->system APIs. However, when there's a human involved (like, when coding against that API), it can be quite nice.

alanctgardner2 14y ago

LinkedIn, Google and Atlassian JIRA's REST APIs all correctly implement HATEOAS. It helps to make your application less brittle when calling a third party API: if they suddenly change how a particular URL is formed, you already know from parsing the HATEOAS. The kind of daft thing is that they provide a separate reference with all those links anyways; they have to uprev the API (and docs) if they actually want to make one of these changes. So, they're doing the right thing, but taking all the good out of it.

specialist 14y ago

I'm on the otherside of the fence. HATEOAS just seems obvious, as in why would someone do it any other way. I recently wrote a client to spider legislation data published as WSDL. Were the reply/result documents HATEOAS, the spider would be trivial. But I have to basically do ETL between every reply and the next request (walking the children of a parent). At the day job, some of the RESTful APIs (written by others) are mostly HATEOAS. It's a pretty big win. Clients are easier, inspection and verification is easier, non programmers almost kinda grok them, etc.