I guess saving payloads with embedded absolute links is also not guaranteed to be perfectly 'restorable' - the absolute server address may change, but overall using absolute URIs seem to be OK for basic default cases,
IMHO It's not a big deal in the end of the day if relative links assume the default value, likewise I don't think it's a big deal if absolute URIs are used by default - the question to experts is which form is more interoperable,
Sergey
________________________________________
From: Sergey Beryozkin
Sent: 31 July 2011 20:31
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: RE: [jsr339-experts] Re: Hypermedia - Take 2
Markus, I think we've just got sidetracked.
I've been advocating the use of @Ref.ABSOLUTE being the default value and you are saying that relative links work great which to be honest I'm not disputing :-).
I'm saying ABSOLUTE are always guaranteed to work; working with relative links may present certain challenges - I don't want to offer hypothetical examples, but
I hope you can agree that working with ABSOLUTE uris is more straightforward and obviously is as RESTful as working with relative URIs
Sergey
________________________________________
From: Markus KARG [markus_at_headcrashing.eu]
Sent: 29 July 2011 17:08
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: Hypermedia - Take 2
I don't understand this problem actually. If a client receives a document
with absolute links, that would be no problem for the client. So if the
server sends relative links, nice. If not, where's the problem? Again, REST
was discovered by looking at the web, and the web uses relative links quite
a lot. So I do not see why we always discuss about problems. Let's discuss
about solutions. If the web is working, JAX-RS can also made working.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Dienstag, 26. Juli 2011 22:56
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>
> 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