Why Web Linking?

[Enrique Amodeo]

Hi everyone, I've been working with web APIs for a while and some time ago I heard about web linking (http://tools.ietf.org/html/rfc5988). After reading the spec I cannot see any scenario where we need the new "Link" header.

In the spec the main use case mentioned is when you want to have a resource that contains binary data, like an image, or a video, or when your resource is not hypermedia enabled. But I think this is a big mistake because the concept of resource and representation are being mixed. I understand that the spec asumes that there is a one-to-one relationship between a resource and a representation, but that is not correct. Any resource can be represented with several mime types, so we are free to provide an alternate representation of the same resource using an hypermedia format, like HTML, HAL, SIREN, etc in addition to the binary data.

For example, you can create a resource at "http://server.com/pics/1" sending a POST with binary data of a picture to the collection URI. If you want some hypermedia controls for the picture, you only need to ask for an hypermedia format in the Accept header. If you want the "image" then you ask for an "image/*" format in the HTTP request. If the same URI can support both binary and hypermedia representations of the resource, why do we need web linking at all?

Perhaps I'm not understood the spec, or there is some use case I do not see, or my reasoning is flawed. 

What do you think about this?

Cheers,

Enrique Amodeo

[Mike Kelly]

Link headers can be used for layering linking protocols on top of HTTP. E.g. Linked Cache Invalidation ( http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04 ) leverages the Link header in responses to point out resources that are invalidated by a given request. Using HTTP headers for this decouples the mechanism from any particular content type of the response which is necessary for a protocol like this, since the response could contain anything from a video to a text file.

They can also be used to add links to legacy responses, and/or to add links to non hypermedia content type responses where forcing an additional request to fetch a link would be unnecessarily inneficient.

I agree that using them in a specific application as anything other than a last resort does not make a great deal of sense. But for generic network protocols and adding links in awkward places they do have good use.

Cheers,
M

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Enrique Amodeo]

Hi Mike, thank you for your response. Using the "Link" header for the use cases you mention makes sense to me.

I'm intrigued about this linked cache invalidation protocol, I'll have a look at it.

Cheers,

Enrique

[Mark Masse]

Thanks Enrique and Mike. This is a very interesting thread. Does anyone know which (if any) of the commonly available HTTP caches supports linked cache invalidation? I am very interested in this model graph expiration idea. Thanks again.

[Mike Kelly]

There's an extension for squid somewhere on mnot's github. There's been some work on a varnish implementation too but not sure if its been open sourced

Cheers,
M

--