mark nottingham

Bringing Back the Link - With a Twist

Thursday, 22 June 2006

HTTP APIs

Recently, there’s been a resurgence for the Link element in HTML; everything from Microformats to Atom autodiscovery is using it. This isn’t surprising; as machines start processing Web documents more, it’s necessary to use hyperlinks — the foundation of the Web — to tie resources together, without getting in users’ faces.

Such linking is useful beyond HTML, of course; Atom defines its own concept of link relationships, and uses them in the Atom Publishing Protocol.

Usually, embedding this kind of link in the content is enough, because the software processing the content is also the software that needs to know about the link. Sometimes, however, that isn’t the case. For example, if we want to discover a link to site-wide metadata of some sort, it might be necessary to give that information to a completely different piece of software that doesn’t know anything about that format. While the metadata can be extracted and sent on, that can be tedious, error-prone, and makes it hard to layer software properly.

What’s the best way to do that? While we could mint a new HTTP header for your link, doing so properly isn’t a small undertaking, and it’s likely that everyone would have to write parsers and serialisers just for its idiosyncracities (just as they would if every new link in HTML and Atom required a new element).

Instead, it would be great if there were something analogous to the Link element in HTTP headers.

What’s Old Is New Again

RFC2068 actually did that; it documented the Link HTTP header in an appendix, but by the time RFC2616 rolled around, it was gone because no-one was using it at the time. While it’s perfectly fine to use the Link header today (it’s in the registry), its disappearance confused some people, and led them to believe that they couldn’t.

To this end, I’ve submitted an Internet-Draft to re-define the Link header, just as it was before. Additionally, the draft defines a Profile header, to serve the same function as the profile attribute in HTML.

Templated Links

But wait, there’s more. Templated links are very useful for building protocols dynamically, without breaking URI opacity. For example, WebDAV defined a whole new method to discover metadata (PROPFIND), when it could have just defined a URI for it, if sites had an efficient way of communicating how to build one.

Link templates do that. For example;

Link-Template: <http://www.example.com/home/{userid}>; rel="home"

tells the receiver of the message that they can figure out anybody’s home URI, given their userid.

I actually have a lot more use cases for this, but they’re going to stay under my hat… for now. For now, I’ll point out that once you have URIs as first-class, typed citizens in HTTP headers, some Semantic Web tools look a lot more interesting. It also becomes easier to extend HTTP in Web-friendly ways.

Comments? Suggestions? Send them to me directly, or to the HTTP mailing list.