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.