3 ms·

> or any way of discovering features of an API programmatically. So, this is one of my issues with HATEOAS. When does this _actually_ come up in practice? I

by xienze 10y ago

> or any way of discovering features of an API programmatically. So, this is one of my issues with HATEOAS. When does this _actually_ come up in practice? I mean really, how do we normally consume APIs? We read the docs to figure out which endpoints we need to call, call them in the right order, and do the right stuff with the result. Nothing about that process is automatic; it takes a human to figure out what's available and the right way to use it. To me the hypermedia part of REST has always seemed like a pointless academic exercise. Yes it's really cool to be able to point a service browser at your service's root resource and have it map the whole thing out but in practice, when is this ever anything but a neat party trick?

danpalmer 10y ago
It means being able to: - Never write a "client" again, use your "REST" library and then just traverse relationships and call actions, rather like an ORM or having a local object graph. - Letting the API provider optimise your usage, by providing different data at different times, inlining at different times, etc, without any changes to your code.
niftich 10y ago
Efforts like the Hypertext Application Language (HAL) [1] are attempts to implement HATEOAS. The point that's often missed in casual discussions of REST is that 'link relations' are extremely important, because they represent well-specified ways of relating one resource to another. They are as critical to REST as mediatypes (MIME types) are. In the graph theory sense, link relations are the label on an edge, URIs are the nodes, and mediatypes are formats that can be used as concrete representations of the nodes. The IANA maintains a Link Relations registry [2]. [1] http://stateless.co/hal_specification.html http://stateless.co/hal_specification.html [2] http://www.iana.org/assignments/link-relations/link-relations.xhtml http://www.iana.org/assignments/link-relations/link-relation...
dragonwriter 10y ago
> So, this is one of my issues with HATEOAS. When does this _actually_ come up in practice? For the type of systems REST is designed to address, all the time. Its not just random happenstance that REST was articulated in the context of an existing, well-known, widely-used system of that type (the WWW.) Arguably, many API designers are neither designing the kind of systems REST is intended for nor designing things for which their priority is for them to be well-behaved components in a distributed system that, taken as a whole, is the kind of system REST is intended for. Which is fine, but then there is little reason to use REST and less to use pretend-REST.

by xienze 10y ago

danpalmer 10y ago

It means being able to: - Never write a "client" again, use your "REST" library and then just traverse relationships and call actions, rather like an ORM or having a local object graph. - Letting the API provider optimise your usage, by providing different data at different times, inlining at different times, etc, without any changes to your code.

niftich 10y ago

Efforts like the Hypertext Application Language (HAL) [1] are attempts to implement HATEOAS. The point that's often missed in casual discussions of REST is that 'link relations' are extremely important, because they represent well-specified ways of relating one resource to another. They are as critical to REST as mediatypes (MIME types) are. In the graph theory sense, link relations are the label on an edge, URIs are the nodes, and mediatypes are formats that can be used as concrete representations of the nodes. The IANA maintains a Link Relations registry [2]. [1] http://stateless.co/hal_specification.html http://stateless.co/hal_specification.html [2] http://www.iana.org/assignments/link-relations/link-relations.xhtml http://www.iana.org/assignments/link-relations/link-relation...

dragonwriter 10y ago

> So, this is one of my issues with HATEOAS. When does this _actually_ come up in practice? For the type of systems REST is designed to address, all the time. Its not just random happenstance that REST was articulated in the context of an existing, well-known, widely-used system of that type (the WWW.) Arguably, many API designers are neither designing the kind of systems REST is intended for nor designing things for which their priority is for them to be well-behaved components in a distributed system that, taken as a whole, is the kind of system REST is intended for. Which is fine, but then there is little reason to use REST and less to use pretend-REST.