4 ms·

Another essay from the same site helped this make more sense to me. If your immediate reaction was "But my code doesn't know how to handle the links in the resp

Another essay from the same site helped this make more sense to me. If your immediate reaction was "But my code doesn't know how to handle the links in the response!", check it out: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

lolinder 3y ago
HATEOAS as designed for humans makes sense, but then REST advocates should really stop calling what they're after a RESTful API and start calling it a RESTful UI. An API is widely considered to be the opposite of a UI—it's the interface that is directed at computers rather than humans. If the key principle of REST is one that is incompatible with computer clients, then a good starting point in a constructive dialogue would be to acknowledge that what they're really saying is that a RESTful API is an oxymoron.
- mercutio2 3y ago
  This authors definition of HATEOAS as being “humans read some text” is bizarre and completely disconnected from what people were talking about at the time. Here’s how HATEOAS is supposed to be helpful for computers: 1. Out of band, humans create complex, useful, well defined media types that cover the space of the functionality they’re trying to define. These need to be well documented. This is where the whole thing falls down 2. Once you’ve got useful media types, you build servers that offer clients a “service document”, a collection of interesting resources (with resources potentially exposed with different media type representations, so newer better media types can be chosen when they’re created in the future, without needing to swap out your server) 3. Servers also define a variety of useful verbs they support, which can also expand over time REST depends heavily on (1). Since almost no one bothers to do (1), the whole project gets tarnished by people trying to do the later stuff and calling it REST.
- eadmund 3y ago
  > If the key principle of REST is one that is incompatible with computer clients Don’t worry, it’s not. While some hypermedia is intended for humans, there is no reason a hypermedia might not be targeted at computers instead.

lolinder 3y ago

HATEOAS as designed for humans makes sense, but then REST advocates should really stop calling what they're after a RESTful API and start calling it a RESTful UI. An API is widely considered to be the opposite of a UI—it's the interface that is directed at computers rather than humans. If the key principle of REST is one that is incompatible with computer clients, then a good starting point in a constructive dialogue would be to acknowledge that what they're really saying is that a RESTful API is an oxymoron.

mercutio2 3y ago
This authors definition of HATEOAS as being “humans read some text” is bizarre and completely disconnected from what people were talking about at the time. Here’s how HATEOAS is supposed to be helpful for computers: 1. Out of band, humans create complex, useful, well defined media types that cover the space of the functionality they’re trying to define. These need to be well documented. This is where the whole thing falls down 2. Once you’ve got useful media types, you build servers that offer clients a “service document”, a collection of interesting resources (with resources potentially exposed with different media type representations, so newer better media types can be chosen when they’re created in the future, without needing to swap out your server) 3. Servers also define a variety of useful verbs they support, which can also expand over time REST depends heavily on (1). Since almost no one bothers to do (1), the whole project gets tarnished by people trying to do the later stuff and calling it REST.
eadmund 3y ago
> If the key principle of REST is one that is incompatible with computer clients Don’t worry, it’s not. While some hypermedia is intended for humans, there is no reason a hypermedia might not be targeted at computers instead.