Sorry, replying at the start of the message as we have an internal email migration and the web-based client does not append '>' properly...
The problem is that we can not guarantee the server will build relative links relative to the current request URI unless we always assume JAX-RS 2.0 declarative hyperlinking feature is always
used there at the other end which can not be guaranteed.
thanks, Sergey
> Anyway, you did not comment on what I said about the ambiguity to do
> with getting a payload with relative links after
>
> link.request().get()
> and
> link.path("bar").request().get()
>
> should the client resolve the rel links against
>
> basePath or basePath + "bar" ?
>
> I'm not saying we should not support relative links, I just feel
> absolute URIs are more interoperable which is important
There is no single base URI for the client but only a base URI for the
request and all the subsequent requests *internally* executed to build the
complete document tree of *that* request (it is a difference whether the
application executes two requests against the same base URI, or whether the
JAX-RS runtime has to run several GETs to resolve a document tree spanned
from relative hypermedia resolution).
So in the first case link.request().get() it resolves against basePath, and
in the second link.path("bar").request().get() it resolves against
basePath\bar.
I do not see any ambiguity here, as the resolution is done within the
"get()" execution, not any later. As soon as get() returns, the document is
already built (it does not contain any URIs anymore -- remember, my proposal
was to load them on the fly and replace them by their original data type!).
Regards
Markus