You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My question is: Wouldn't it be better for an API-consumer to have JSON-HAL conform JSON-Response available?
Otherwise a consumre would have to implement API logic in the client code and could not rely on abstract REST-traversel features provided by HATEOAS using e.g. the Traverson library in Spring-Boot or in Javascript.
So instead of implicit knowledge on client side, each REST-Response (and so the server-side) would include the knowledge about how to traverse / use the API for further information, following the factoid model. E.g. instead of providing ids in the response, we could use full urls in an HAL-conform way to inform a consumer on how to further use rest-parameters / what further paths are etc.
My question is: Wouldn't it be better for an API-consumer to have JSON-HAL conform JSON-Response available?
Otherwise a consumre would have to implement API logic in the client code and could not rely on abstract REST-traversel features provided by HATEOAS using e.g. the Traverson library in Spring-Boot or in Javascript.
So instead of implicit knowledge on client side, each REST-Response (and so the server-side) would include the knowledge about how to traverse / use the API for further information, following the factoid model. E.g. instead of providing ids in the response, we could use full urls in an HAL-conform way to inform a consumer on how to further use rest-parameters / what further paths are etc.
HAL Spec:
http://stateless.co/hal_specification.html
Example of JSON-HAL:
The text was updated successfully, but these errors were encountered: