3 ms·
I thought the general idea is to code the client against a well defined and sanctioned media type. If the media type returns items and actions, a well coded cli
by dsego 8y ago
I thought the general idea is to code the client against a well defined and sanctioned media type. If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). The point of returning actions is that URLs change, and must be able to change. Instead of following HATEOAS guidelines, people hardcode routes and lament about how URLs should be structured (flat vs nested, e.g. `/posts/1/commment/4` vs `/comments/4`) and then they also have to be versioned etc. (`api/v2/posts`). Now that is silly.
- philwelch 8y ago> If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). In a web service context, is there a HATEOAS web client library that I can use to make service calls without having to specify endpoints and request formats ahead of time? > Instead of following HATEOAS guidelines, people hardcode routes...and then they also have to be versioned etc. (`api/v2/posts`). In the web service use case, it's considerably simpler to define and specify a set number of endpoints ahead of time, define request and response formats, document that specification in OpenAPI, and use versioning if the API itself changes. This isn't RESTful. It's just RPC over HTTP. But it works and it's not "silly".