Here's a related discussion at IETF about Web Linking, which has allowed us to vastly simplify the descriptor format by moving linking meta-data to the HTTP headers (where it arguably belongs). Sam ---------- Forwarded message ---------- From: Sam Johnston <samj@samj.net> Date: Mon, Jun 15, 2009 at 5:27 AM Subject: Clarifications on Web Linking with HTTP To: apps-discuss@ietf.org Morning all, The HTTP Link: header enables web linking without hypermedia - that is, arbitrary content types can be linked (with attriubtes) out-of-band rather than within the payload (e.g. HTML) itself. This enables the use of HTTP as a meta-model (at least for individual resources) without having to resort to Atom, which is potentially great news for RESTful APIs. I am currently working on a real world application of Marks' Web Linking I-D[1] (OGF's Open Cloud Computing Interface - http://www.occi-wg.org/) and require clarification on a few points (which may want to end up in the I-D). - First and foremost, in the absence of the LINK and UNLINK verbs originally defined in RFC 2068[2] but specifically omitted from RFC 2616[3], what is the preferred mechanism for manipulating these links via HTTP? It appears that this header is intended for GET requests only, but presumably specifying it in POST and PUT requests would be one option that avoids the creation of [not so] "new" verbs (bearing in mind that short of accepting Link: headers from empty POST/PUT requests, it would be necessary to GET and then PUT the entire payload to update links - twice if they were reciprocal). While there was an attempt a dozen years ago to better define the relevant HTTP verbs[4], it strikes me as more sensible to follow the example of the Set-Cookie: header for this rather than WebDAV's example of creating new verbs (even if we've seen them before) but you guys are the experts. - Another concern with an arbitrary number of links is that arbitrary string length limits may be imposed by user agents, as they are with URLs. This should not be a problem where there is one link per header, but it may be where the headers are concatenated as described in RFC 2616[5]. This is a double edged sword however as some user agents have only recently added support for multiple headers of the same type[6] and it remains a problem for some[7]. - The introduction of a link relation registry at IANA makes a lot of sense, though it would be nice if these were common for HTTP, HTML, Atom and other places links appear. Perhaps namespaces (e.g. "atom:service" or "occi.state.restart") would be useful here so as to enable significantly more future extensibility. - It seems useful to be able to (optionally) specify the type (as in content type rather than relation type) of a given link, as is the case for Atom. That said, this also seems somewhat redundant with HTTP Content Negotiation, but implementations that choose to support the "type" attribute may gain some performance and usability advantages from doing so. The matter of whether this information belongs in URIs (and if so, which side of the '?') or in HTTP headers (or both) is still not clear to me as there are pros and cons of each - perhaps the relation type is more suitable (or both?) as it's often not possible to unambigously determine the relation type from the content type (consider modeling people where both fingerprint and portrait representations may exist in image/png format). To be more specific about the requirements, the API models cloud infrastructure services (IaaS) and has three main nouns (compute, network, storage) which need to be associated with each other with attributes on the links (e.g. a compute resource having a network resource associated with a local identifier attribute of "eth0"). Using Atom as the meta-model worked fine (as evidenced by GData) but it now seems possible - at least for individual resources - with HTTP. Cheers, Sam 1. http://tools.ietf.org/html/draft-nottingham-http-link-header-05 2. http://tools.ietf.org/html/rfc2068#section-19.6.1 3. http://tools.ietf.org/html/rfc2616#section-19.6.3 4. http://ftp.ics.uci.edu/pub/ietf/http/draft-pritchard-http-links-00.txt 5. http://tools.ietf.org/html/rfc2616#section-4.2 6. http://www.mail-archive.com/bug-wget@gnu.org/msg00076.html 7. http://bugs.python.org/issue1660009