jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Hypermedia - Take 2

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 2 Aug 2011 18:59:37 +0200

Hi Marek

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' :-)

>
> 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.

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...

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
>>