Subject: Clarifications on Web Linking with HTTP

From: Sam Johnston <[email-masked]>
Date: Mon, 15 Jun 2009 05:27:01 +0200

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/[email-masked]/msg00076.html
7. http://bugs.python.org/issue1660009

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Jun 2009 14:20:26 +1000

Hi Sam,

> new verbs (even if we've seen them before) but you guys are the

Undefined, but I imagine in a PUT/POST body does indeed make the most  
sense. Using the Link header in a request doesn't have well-defined  
semantics.

> and it remains a problem for some[7].

Yes, this is true for most things. Not much that can be done about it  
beyond writing resilient software...

> enable significantly more future extensibility.

Having a common registry is the whole idea behind the draft;  
similarly, extensibility is explicitly provided for (using URIs)...

> representations may exist in image/png format).

Not sure there's a question in there...

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Sam Johnston <[email-masked]>
Date: Tue, 30 Jun 2009 13:49:02 +0200

> Hi Sam,

Thanks for getting back to me about this - your input is appreciated.

>> via HTTP? <snip>

I think it would be something that's worth defining, albeit perhaps not in
your current I-D at the 11th hour and after 6 revisions. It's just not clear
to me what (outside of dedicated HTTP verb(s)) makes the most sense... I'm
yet to come up with a reasonable way to do it in-band.

>> case for Atom. <snip>

Basically just observing that the "type" attribute is conspicuously absent
from your Link: header I-D and wondering whether that's sensible (e.g. are
there times when it makes sense to specify/advertise the type ala Atom - and
I think there are - for example when you're dropping the Atom wrapping for
individual resources as we're trying to do with OCCI).

Sam

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 Jul 2009 14:23:47 +1000

type is in the BNF, just not the prose; will say something in the next  
draft.

Thanks,

On 30/06/2009, at 9:49 PM, Sam Johnston wrote:

> Undefined, but I imagine in a PUT/POST body does indeed make the  
> most sense. Using the Link header in a request doesn't have well- 
> defined semantics.
>
> I think it would be something that's worth defining, albeit perhaps  
> not in your current I-D at the 11th hour and after 6 revisions. It's  
> just not clear to me what (outside of dedicated HTTP verb(s)) makes  
> the most sense... I'm yet to come up with a reasonable way to do it  
> in-band.
>
>
> Basically just observing that the "type" attribute is conspicuously  
> absent from your Link: header I-D and wondering whether that's  
> sensible (e.g. are there times when it makes sense to specify/ 
> advertise the type ala Atom - and I think there are - for example  
> when you're dropping the Atom wrapping for individual resources as  
> we're trying to do with OCCI).
>
> Sam
>