Web Linking

one of the main components of REST is linking (modeling applications as hypermedia, i.e. interconnected resources), and more specifically, typed linking, where a link not only specifies where it links to (in web-oriented systems this is always done using URIs), but what it links to, so that clients can choose which links to follow. in many cases, these link types are application-specific, but there also are link types which are fairly universal, and which should be reused across applications instead of being reinvented many times.

so far, link relation types were defined within the confines of applications and/or representations; both HTML and Atom/AtomPub, for example, define their own link relation types, and those are only expected to be used for these specific representation types.

the recently published RFC 5988 (Web Linking) specifies relation types for web links more generally, and defines a registry for them. it also defines the use of such links in HTTP headers using the Link header field. this means that from now on, links for RESTful application do not (necessarily) have to be embedded in representations anymore. instead, if they pertain to the requested resource, they can be communicated in a Link header field, which is specifically mentioned to be semantically equivalent to HTML's <link> element and Atom's feed-level <link> element.

the immediate advantage of this approach is that links can now be used for resources where the representation does not define a place to put them, and that resources do not have to be parsed to find links connecting them to other resources. in fact, by using HEAD requests, resources do not even have to be retrieved to find the links that link them to other resources, which means that Link-aware clients can traverse RESTful services in a much more efficient way, as long as all they need are resource-level links.

adding to my REST Programming Toolbox Requirements, i would thus expect a good REST programming toolbox to start supporting the Link header field, and to allow applications to more or less ignore the fact whether a link has been found in resource, or in a Link header field. ideally, a toolbox might even be smart enough to optimize requests, so that HEAD requests are used whenever only resource-level links are required in cases where the server supports the Link header field. this, however, requires knowledge of whether the server will reliably serialize all links as Link header fields, and this is not something that can be determined automatically; a programmer would have to configure that.

in addition to the initial link types defined by RFC 5988, RFCs 5829 (Link Relation Types for Simple Version Navigation between Web Resources) and 5989 (A SIP Event Package for Subscribing to Changes to an HTTP Resource) have added values to the registry so far, and over time the registry should grow as a place where RESTful applications can look up, reuse, and add link relation types for hypermedia-driven applications.

since RFC 5988 extends the way in which link types should be handled in Atom and can be exposed by HTTP servers publishing Atom, i have restructured the Atom Landscape Overview to start listing any RFCs (or drafts) that might add link relation types to the link relation type registry. as usual, any feedback to further improve the overview is greatly appreciated.

Comments

[zazi]

Please correct me, when I'm getting wrong here (I come originally from the Semantic Web corner). However, one issue where I stumble up again and again, while trying to understand REST as defined by Roy T. Fielding, is the issue with link types. I know i.e. HTML hasn't much link relation types defined out of the box. For me a link is a binary relation in its nature, which can be type (if its not typed, then we have at least one type ;) ). When looking behind the scene of RDF Model, one will also find that binary relation, that is identified by the predicate position of an RDF triple. Due to its metamodel they are called properties, which are typed. So every property assigns a specific relation type. I don't see any need for a central link relation type registry, since one can simply resolve the property URI and should ideally get a description that describes the processing model of that link type human and machine understandable (processable). Furthermore, I thought decentralization is one of main success criterias of the Web. So why working against this constraint?
All in all, why not simply applying RDF Model for that issue, i.e. as it is propagated recently with RDFa? I think the knowledge representation structure of RDF Model is quite ideal therefore.

[dret]

http://dret.typepad.com/dretblog/2009/10/links-in-html.html is a list of link types defined in HTML out of the box. some are implicit in the elements (if a link is found in , it must link to an image, which will probably be embedded by the browser's rendering engine). This simple model has made google possible (follow links to hopefully more text to be found in other HTML, and ignore images, unless you're building google image search, of course). how would you envision the "imageness" of a linked resource to be discovered dynamically when encountering such a link? the success of the human web lies in the fact that the simple set of link types is hardcoded in HTML, so all clients (mostly browsers and crawlers) know how to deal with it. the link type registry adds a modest amount of extensibility to that model.

take a brief look at the link types in the registry so far. some for example provide paging mechanisms for paging through an atom feed (those are expected to be found in atom feeds). how would you imagine these semantics to be expressed in a way so that they can be understood at runtime? what the link registry does is provide a place where i can find pointers to conventions/standards for link types, and these are about interaction semantics. clients need to implement/support these interaction semantics to make use of these link types, and i haven't seen a semantic framework that would allow to express the fact that a link found in a feed has the semantics of linking to the "next page of feed entries", and that a GET on this URI will result in a feed that contains this next set of entries. or even more extreme, it is very hard to imagine a semantic framework that could fully express the semantics of the action="URI" in an HTML . you need documentation to describe the protocol, and the link type registry can point you to that documentation.