Is there a consensus?



An absolute URL is, I guess, easier to consume by a client, whereas a

relative link is also going to need some sort of (equivalent to HTML)

BASE tag so that the client can build the URL to hit.



On the other hand I quite like the idea of a relative URL... for example

one could take a set of representations and - with only a tiny bit of

mangling of the BASE tag within them - replay them, eg for

performance/load testing - in some other environment.



Thoughts?



Dan

Dan Haywood wrote:

>

> Is there a consensus?

>



Yes, that URI allocation scheme design is off-topic to REST.  ;-)



Pragmatically speaking, decent URIs make it easier to develop and

maintain RESTful systems to the point where your question is not off-

topic to rest-discuss, though...



>

> An absolute URL is, I guess, easier to consume by a client, whereas a

> relative link is also going to need some sort of (equivalent to HTML)

> BASE tag so that the client can build the URL to hit.

>



You don't *need* a <base> tag, in its absence URLs are relative to the

current representation's URI.



>

> On the other hand I quite like the idea of a relative URL... for

> example one could take a set of representations and - with only a

> tiny bit of mangling of the BASE tag within them - replay them, eg

> for performance/load testing - in some other environment.

>



True, that.  Taking that thought a bit further, the real power is that

you can write relative algorithms to generate navigational links, which

work regardless of how deep in a hierarchy a page is, without caring

about the path; instead of parsing or calculating redundant path info,

as is required to generate absolute URIs.  This can significantly

reduce latency at the origin server on cache misses, etc.



This is what led me to my stub-file approach for browser-resident XSLT

REST applications -- if the URI allocation scheme is algorithmic and

relative URIs are used, a significant number of stub files site-wide

become identical and can share Etags.  A little logic on the server can

bypass generating stub files for whole swathes of resources, in favor

of serving a cached representation.  On the client, anything which

hastens initiation of the cached, compiled transformations is a big

user-perceived performance win.



Sometimes, there are fringe REST benefits to rational URI allocation

scheme design and relative URLs.



-Eric