HATEOAS and rest client about microprofile-rest-client

[t1]

@konjp The discussion about the pros and cons of HATEOAS are tiresome. It probably can be solved as easy as the discussion about tabs and spaces.

But you have a very specific problem at hand that could be solved even with the static nature of the MP Rest Client (if it's not too late): You can simply add a List<Link> links field to your Management DTO. The Link class would have fields for href, rel, and type. Then you can handle the navigation 'by hand'.

If that's a satisfying response for you, we could close this issue.

[andymc12]

Unfortunately, I don't think MP Rest Client is a good fit for HATEOAS-based services. If the endpoint URIs remain mostly static (fixed) then you could write your client interface based on the data in the link section.

The issue I see with it is the dynamic nature of HATEOAS - I've seen examples where different URIs become available/unavailable based on certain conditions - i.e. a banking service that won't allow you to execute the "withdraw" URI if your account balance is too low. The MP Rest Client interface would still either have the withdraw method or it wouldn't - but the interface methods are fixed (without altering the client side application code). In a use case like that where certain URIs are unavailable, I would assume that the server would respond with some status code indicating that the URI is invalid (404 or maybe 403, 405, etc.) - in that case the client application could register a ResponseExceptionMapper to throw an application-specific exception (i.e. InsufficientFundsForWithdrawalException) when that unavailable URI is invoked via the rest client interface.

As far as handling the response data, you could use the built-in JSON-P APIs (JSONObject/JSONArray) as return types - or use return types that are specific to your application, but then you might need to register a MessageBodyReader to convert the JSON response into the app-specific object. In either case, I would probably ignore the links section unless you wanted to be aware if the remote service added some new URI(s).

Hope this helps,
Andy

[derekm]

RFC says all Links should be in headers, not in documents.

Otherwise HATEOAS links are not URL-rewriting proxy-safe.

If MP Rest Client takes this same headers-only, URL-rewriting-safe view, it could probably accommodate HATEOAS, as well as demonstrate the correct approach to all the people the world over who a "Doing It Wrong™."

[derekm]

In other words, MP Rest Client should only support: https://tools.ietf.org/html/rfc5988

As @andymc12 says, Links in content type bodies cannot be supported (and should not be supported, because it is an entirely broken and bad approach).

[konjp]

Like in most case when we have problems, they almost always come as chain of events :-). In this particular case we do not have control of rest endpoint and we need information from links section, therefore it is not option to ignore links.

In team we already discussed situation that @andymc12 mentioned. Endpoint is not much dynamic, therefor static (fixed) approach from client side is a option. I know somebody can say then you do not facilities one one major advantage HATEOAS like structure, namely that server can evolve independently from client.
Solution that we think to implement to follow links and get content is given bellow like pseudo-code:

foreach link in links and type='GET' do 
RemoteApi remoteApi = RestClientBuilder.newBuilder().baseUrl(link.url).build(RemoteApi.class);

@derekm can you little elaborate more on how URL rewrite is done on client side.

Just to add little bit to discussion about linking, a lot of implementations f.e. HAL, Siren or Atom have linking implemented in content body.