On Feb 16, 2010, at 1:18 PM, Marc Hadley wrote:
> On Feb 16, 2010, at 1:04 PM, Markus Karg wrote:
>>
>> Do you now understand why I say that the only valid place is inside of the
>> entity (because the entity format is known to the client, while the use of
>> the headers is not)?
>>
> Surely if you can teach a client about the links it might find in an entity you can also teach it about links it might find in headers too ? Actually this seems essential when certain headers are considered part of the hypermedia.
Exactly.
I feel we discussed this already, but it's again about whether you do this in the application or you factor it out in a framework.
If it is part of the application logic, you can put hyperlinks anywhere (including headers) but it's probably more natural for them to be in the entity. If it is part of framework logic, the framework needs to know about their location and Link headers make more sense because (i) you always know where they are and (ii) they do not depend on the representation format (JSON, text, etc.) supporting links, as was pointed out by Roy.
As I believe Jan mentioned, links in entities and framework support would require some sort of HyperlinkProvider associated with application media types. Perhaps implementing something like:
public interface HyperlinkProvider<T> {
public Map<String, URI> getHyperlinkRelations(T r);
}
and registered in ClientConfig (for each media type the application uses). The method would return a map of rel's to links, and hopefully the framework would be able to do something useful with this info. I suppose something similar could be done on the server side, but a declarative solution seems difficult when the app is responsible for serializing the hyperlinks ...
-- Santiago