In my previous post I was casting around for an alternative to
type as the name of a link header attribute, since in the standard this refers to a content type, not the “logical” type of the resource pointed to by the link.
I have decided to go with
role, borrowed from XLink. I know that we’re not dealing with XML here and XLink isn’t wildly popular, but it’s documented, accepted and understood, so why reinvent the wheel?
Consistent with both XLink and the existing
rel attributes, I’ve made these
role attributes contain URIs, as in this example:
Link: <http://example.com/users/dojo>; rel="self"; role="http://example.com/described_routes#user", <http://example.com/described_routes/user>; rel="describedby"; role="http://example.com/described_routes#described_route", <http://example.com/described_routes/user?user_id=dojo>; rel="describedby"; role="http://example.com/described_routes#ResourceTemplate", <http://example.com/users>; rel="up"; role="http://example.com/described_routes#users", <http://example.com/users/dojo/edit>; rel="edit"; rel="http://example.com/described_routes/user#edit"; role="http://example.com/described_routes#edit_user", <http://example.com/users/dojo/articles>; rel="http://example.com/described_routes/user#articles"; role="http://example.com/described_routes#user_articles"
You can think of this in terms of entities and relationships in the ER model:
identifies a target entity (“user_articles” in this example, named after its Rails route) within the overall schema, and
identifies a relationship (“articles”) within the description of the source entity (“user”).
These URIs are globally unique, and even if they are never dereferenced by the client (i.e. the client isn’t interested in the
ResourceTemplate metadata there – shame on them!), these values can be used by clients to select links reliably.
One of my sources of both good practice and inspiration has been Tim Berners-Lee’s Design Issues. I hadn’t got to the Metadata Architecture article until after drafting the above, and it’s quite gratifying to read it now. Tim makes the ER comparison too, but rather than rehash that I will quote some of his key principles:
Metadata about one document can occur within the document, or within a separate document, or it may be transferred accompanying the document.
Link headers and link elements pointing to ResourceTemplate documents exemplify all three possibilities.
The URL space is an appropriate space for the definition of attribute names
Not only appropriate, but a lot more powerful than arbitrary tokens. My initial plan to use simple names for
type attributes were definitely misguided.
As much as possible of the syntax and semantics should be able to be acquired by reference from a metadata document.
Within the scope of defining navigations around a web application I think this is achieved successfully. A lot can be done by the client even without the metadata document, though clients will still need help in constructing URIs for members of collections. I think there would a be place for the ResourceTemplate format (or something very much like it) even if there was a standard for URI Templates in link headers, but that’s a whole new article, perhaps my next one.