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
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.