Meaning that all type of clients can understand how to work with a given link.
Example, if say I'm using a generic Atom reader which gets a feed with rel links bubt without xml:base then
if we can find at least 1 client that fails to convert rel links to absolute ones then I'd say using relative links in
that specific context is not interoperable
Cheers, Sergey
________________________________________
From: Markus KARG [markus_at_headcrashing.eu]
Sent: 01 August 2011 17:59
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: Hypermedia - Take 2
Interoperable in which context?
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Sonntag, 31. Juli 2011 21:43
> To: Sergey Beryozkin; jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>
> 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
>