Hi,
>
> Please see comments with S.B
> ________________________________________
> From: Marek Potociar [marek.potociar_at_oracle.com]
> Sent: 02 August 2011 13:37
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Sergey Beryozkin
> Subject: Re: [jsr339-experts] Re: Hypermedia - Take 2
>
> On 07/30/2011 08:09 PM, Sergey Beryozkin wrote:
>> Hi Marek
>>
>> My point is that the resolution of relative links is not entirely portable.
>> I'm not saying relative links can not be used effectively - what I'm saying in the end of the
>> day is that having ABSOLUTE being a default value of @Ref seems OK for me,
>
> +1. Absolute as a default is obviously more interoperable (or portable, to use your terminology).
>
>> S.B - I actually did not mean 'portable', it just got typed out somehow and then I realized I actually meant 'interoperable' :-)
FWIW, on a second thought, Jan may have a valid point here - relative links may be significantly more efficient esp.
when used as part of small message payloads. Having "workaround" the option for ill-behaved clients may be good enough
and we may not need to trade the default efficiency for interop in this case.
S.B. That's OK.
Personally, the idea of writing the client code which checks the links and then goes and builds absolute URIs as opposed to doing immediate GET
makes me a bit nervous, especially that I will probably write not a very good server code which will 'cost' WEB extra "
http://myhost.com" per link :-)
But of course it's up to a concrete application code which does decide to use @Ref on which form the links should take, so I'm going to support
whatever decision the group takes
Cheers, Sergey
>
>>
>> and back to your question,
>> we don't know at the client side whether the relative links have been created from the original base URI the client used or
>> from the current URI, and 'should' is not a strong enough guarantee. Saving payloads and restoring them afterwards may present
>> another issue as far as the resolution is concerned.
>
> Can you provide an example. Seems I got lost again. Sorry :)
>
>> S.B np :-).
>
> The server has been injected with @UriInfo and it supports handling multiple URIs, it was coded to build relative URIs using uriInfo.getBaseUriBuilder().
> The client issues a GET request to /foo and resolves relative URIs relative to /foo. Next it moves on to /foo/1, issues GET and resolves rel references relative to
> /foo/1 - as it happens the server was still using /foo as the base URI when creating relative links.
To resolve relative references in such case one would need to work with uriInfo.getRequestUriBuilder() instead of
uriInfo.getBaseUriBuilder() IMHO. Failing to do that could be considered as a bug in the application impl.
>
> Re saving the payloads: we restore the payloads with relative links but the base URI value is not there - extra effort is needed to retain it too...
Would saving the payload together with the base URI solve the issue? Seems to me it would.
Cheers,
Marek
>
> Cheers, Sergey
>
>
> Marek
>
>> Both ABSOLUTE and RELATIVE links can work OK, the question as far as I understand what the default value is.
>>
>> Cheers, Sergey
>> ________________________________________
>> From: Marek Potociar [marek.potociar_at_oracle.com]
>> Sent: 27 July 2011 19:41
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Cc: Sergey Beryozkin
>> Subject: Re: [jsr339-experts] Re: Hypermedia - Take 2
>>
>> 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
>>>