It is costly to peer into content bodies, moreover, content is typically not very loggable, while headers are a no-brainer. The more appropriate and useful stuff in the headers or uri, the better. Link-template is fine, too, provided it keeps the parsing syntax of normal Link.

Link-Foobar: http://…/barfoo
Link-Definition-Foobar: http:/…/foobar/link/definition
Link-Type-Foobar: image/jpeg

A “Link-Definition-*” wouldn’t be needed for registered links.

In all, i just became annoyed when I wanted to write a simple Ajax demo with the stuff I’m doing and realized I had to learn a bit more javascript than I wanted to which I had already done once for a Java client.

Hence the Set-* pattern which is fully compatible with today’s infrastructure and has some hope of surviving as a standard (as it doesn’t take over the entire header namespace as setting arbitrary headers – something I started with – would).

Sam

I like the Set idea. As for Set-Link: I’ve also seen LINK and UNLINK methods in older versions of HTTP.

While I appreciate your concerns about the Link headers I think it’s best we just write some parsers for people to use and possibly try to have them included in user agents. That or try to fix the draft somehow? Remember there could be an arbitrary number of headers so before long you’ll be saying stuff like Link-1-Name: blah and wishing you’d never gone down that path.

My larger concern is about clients being able to manipulate the link headers and for that I’ve proposed following the Set-Cookie example with a Set-Link header. Similarly I have a [Set-]Category header for organising information and [Set-]Attribute for “server side cookies”. This results in a very flexible meta-model that I think may well be aligned with what you’re trying to achieve with REST-*.

Sam