Sergey,
On 07/26/2011 10:55 PM, Sergey Beryozkin wrote:
> 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.
Not sure I understand your point correctly, but resolving relative URIs is a well defined process:
http://tools.ietf.org/html/rfc3986#section-5
I believe that when sending/receiving relative links, both, client and server, should conform to the process above when
producing/consuming relative links. Nothing JAX-RS specific needs to be involved or assumed.
Marek
>
> 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
>