6 ms·

> Optimizing for HATEOAS seems to me to be optimizing for entirely the wrong metrics, and a complete waste of development time and effort. It depends, it's jus

by eterps 10y ago

> Optimizing for HATEOAS seems to me to be optimizing for entirely the wrong metrics, and a complete waste of development time and effort. It depends, it's just a way to reduce coupling between a webservice and its client apps. Instead of hardcoding all the URL endpoints into the client, the client has to follow the links provided by the webservice instead. If this layer of indirection has advantages for you depends on your use case. You could compare it to using DNS instead of static IPs. Static IPs work fine but you end up with more coupling than using DNS.

richardwhiuk 10y ago
If I remove the reference to a link in the response, it doesn't remove the clients need to: a) know how to retrieve that link (i.e. what resource do I need to retrieve in order to get that response) b) requirement for that link to exist (they still need that link). Requiring that a client know that to get data Bar, they need to retrieve resource A, follow the link at foo[n]._link to retrieve resource B, and then following the link at _link.bar feels like a total non starter, and actually increases coupling.
- eterps 10y ago
  I am not sure I get your example. But yes the client still has to know what to do in advance.
  - edmccard 10y ago
    >But yes the client still has to know what to do in advance. According to Roy Fielding[1] (who came up with the concepts of ReST and HATEOAS: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience" So if an application doesn't rely on "standardized media types", and "the client still has to know what to do in advance", then it seems like whatever you're doing, it isn't HATEOAS after all. [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
    - kelnos 10y ago
      I don't think you and your parent mean the same thing. The client "has to know what to do in advance" in the sense that the human building the application needs to know what user interface they want to build, and know how the API works (in advance) in order to use it to populate the interface. If you have an extremely dumb interface that just displays fields in API responses, then ok... but that's a very trivial UI that accounts for... basically no useful products ever.

by eterps 10y ago

richardwhiuk 10y ago

If I remove the reference to a link in the response, it doesn't remove the clients need to: a) know how to retrieve that link (i.e. what resource do I need to retrieve in order to get that response) b) requirement for that link to exist (they still need that link). Requiring that a client know that to get data Bar, they need to retrieve resource A, follow the link at foo[n]._link to retrieve resource B, and then following the link at _link.bar feels like a total non starter, and actually increases coupling.

eterps 10y ago
I am not sure I get your example. But yes the client still has to know what to do in advance.
- edmccard 10y ago
  >But yes the client still has to know what to do in advance. According to Roy Fielding[1] (who came up with the concepts of ReST and HATEOAS: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience" So if an application doesn't rely on "standardized media types", and "the client still has to know what to do in advance", then it seems like whatever you're doing, it isn't HATEOAS after all. [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
  - kelnos 10y ago
    I don't think you and your parent mean the same thing. The client "has to know what to do in advance" in the sense that the human building the application needs to know what user interface they want to build, and know how the API works (in advance) in order to use it to populate the interface. If you have an extremely dumb interface that just displays fields in API responses, then ok... but that's a very trivial UI that accounts for... basically no useful products ever.