> 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.
Great that finally my intial cause for being against absolute got understand now in the end. Was a long road. I wonder what actually anybody thought why we did so badly want relative as the default? ;-)
> >> 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.
+1
> > 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.
Don't want to warm up old threads, but saving payload together with base URI smells like some re-use of data a client-sided cache already contains. ;-)