> Metadata is your friend. Indeed, it is difficult to understand how
> one could compose a generic client that didn't understand at least all
> the Content-* headers.
No doubt about that. The problem is whether you can write a generic REST
client. Currently, the answer still is: Only if the links are in the
content. Why? Because the only "valid" place in http headers would be
"Link", not "anything" (but we currently discuss "anything"). How every
should a client know to look in "anything" without being specialized to one
particular application or framework? How to tell all the callers of my
server that they must inspect "anything", not just "Link"? I don't doubt
that headers are part of the representation, but to make any client work
with any header, the only valid place still is "Link" (not from the aspect
of the dissertation but from the aspect of "how could it ever work?").
> I agree with you that embedded links are nice (from an aesthetic point
> of view), but they are not always practical. I'm not always in
> control of the format of the message body itself (a bitmap image
> doesn't provide much opportunity for injecting links; neither does an
> XML message conforming to some application schema that didn't include
> them), so I still need a way to express the relationships. Given that
> a client needs to deal with metadata anyway, expressing links there
> isn't good or bad, it is just different.
Sorry for not posting here -my fault-, but I already agreed to the IMAGE
problem actually, when I yesterday updated my blog about HATEOAS. :-) About
XML, there is a difference: In the XSD I AFAIK can define which attribute is
an XLink, so it is a rather easy XPath task to find out any XLink from any
(correctly XSD'd) XML. Certainly, if there is no XSD used, this is
impossible.
But it seems we're talking about a wide span of things: On one hand, you say
I cannot control the content of the server when writing the generic client,
on the other hand, Jan says that he even can control the implementation of
the client when he's writing the server... ;-) Looks like we're talking
about completely different types of what "client" means.
To conclude, I agree that the "Link" header would be a good place, but not
any other header. I actually agree that for a generic client, it might be a
better place than the content itself, since it removes the need to add a
content parser factory.
Markus