Certainly absolute links are also restful, but I don't see what should be
more straightforward with it? Each browser is doing relative links without
problem, so it obviously is straighforward, too (but certainly more complex
to implement).
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Sonntag, 31. Juli 2011 21:32
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [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
>