Loading ...
Sorry, an error occurred while loading the content.
 

absolute or relative URLs in links?

Expand Messages
  • Dan Haywood
    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
    Message 1 of 2 , Nov 10, 2011
      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
    • Eric J. Bowman
      ... Yes, that URI allocation scheme design is off-topic to REST. ;-) Pragmatically speaking, decent URIs make it easier to develop and maintain RESTful
      Message 2 of 2 , Nov 10, 2011
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.