3 ms·

I love HATEOS style APIs as a user, but not as a developer building them. Because they're not trivial to build and creates a lot of coupling between systems. F

I love HATEOS style APIs as a user, but not as a developer building them. Because they're not trivial to build and creates a lot of coupling between systems. For example, if I have a device, which belongs to organization, HATEOS advises me to include a link to `organization` object and how to get there. But, if I am writing a microservice for devices or any other isolated logic from organizations model and how organizations model is exposed externally. Now I need to create coupling between 2 systems and know how to address owner `organization`.

dragonwriter 3y ago
> For example, if I have a device, which belongs to organization, HATEOS advises me to include a link to `organization` object and how to get there. If it is a general purpose interface, you probably want at least one representation of devices that exposes the organization. You may also want one that doesn’t, and you may not want any that do. There’s no violation of HATEOAS in having collections that link to leaf nodes but leaf nodes not linking to collections they may be part of. All HATEOAS really says is that if you want clients to be able to get from the device to the owning organization, then you should include a link to the organization in the representation of the device rather than relying on the client interpreting the structure of the URI of the device to infer the associated organization. Hypertext as the engine of application state does not have strong opinions on what navigation or state transitions are supported, only that those that are supported should be supported via hypermedia techniques of in-representation locators for location, methods with well-defined semantics operating against the resources at those locations, and representation types (e.g., media types), with each serving its particular purpose.

dragonwriter 3y ago

> For example, if I have a device, which belongs to organization, HATEOS advises me to include a link to `organization` object and how to get there. If it is a general purpose interface, you probably want at least one representation of devices that exposes the organization. You may also want one that doesn’t, and you may not want any that do. There’s no violation of HATEOAS in having collections that link to leaf nodes but leaf nodes not linking to collections they may be part of. All HATEOAS really says is that if you want clients to be able to get from the device to the owning organization, then you should include a link to the organization in the representation of the device rather than relying on the client interpreting the structure of the URI of the device to infer the associated organization. Hypertext as the engine of application state does not have strong opinions on what navigation or state transitions are supported, only that those that are supported should be supported via hypermedia techniques of in-representation locators for location, methods with well-defined semantics operating against the resources at those locations, and representation types (e.g., media types), with each serving its particular purpose.