> > BTW, as the web
> > is the prototype of REST, and the web typically is using relative
> URLs in a
> > massive way, we should really discuss the benefit of relative URLs
> (better
> > security as both parts must be in the same domain, less data to
> transfer and
> > process). Every browser comes with a resolver for that, so it should
> be
> > fairly easy for the Client API implementation to resolve relative
> URLs
> > received in responses (as it knows the base URL that the request was
> sent
> > to).
>
> I guess if HTML representation is returned than yes, relative links
> should world OK, otherwise it's an extra effort for the client code to
> deal with such rel links ? We can get URIs relative to the base URI,
> but
> also perhaps relative the currentURI, example, GET has been made after
> baseURI + several path()s ? I can imagine a large payload duplicating
> the info like "http://host:port/order" - for cases like this we should
> encourage users use relative links if feasible.
> By the way, I think there should be a way to express that a response
> xml
> representation needs to have xml:base attribute for resolving relative
> links
For what do we need that base URI? I mean, if my browser does a request to
http://www.foo.de/bar/x/y/z.html, and that html contains <img src="i.png"/>
then all browsers on this earth are able to assume a base URI of
http://www.foo.de/bar/x/y. So why should the client engine behave anything
different? And what do you mean with "additional effort" -- we just talk
about splitting a path from a file in world of 3+ GHz MultiCore laptops.
Have you every computed the actual costs you are complaining about? ;-)
Regards
Markus