> 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 ...
The problem that would be still unsolved is that the client must also learn
about this. Certainly you can write a particular client for each application
or framework, or you can make a client pluggable. But what about third party
applications that need to communicate with your service? I don't like the
idea that I have to provide lots of plugins for all the third party
applications that like to access my service. In contrast, if we reduce the
use of headers to "Link" (and the standardization is done), then any client
could communicate with our server, and there is no need to specialized
clients. And then, it is no problem to provide a generic client and call it
from a process script, which would completey factor our the application
specifics from the client, allowing to use it for *any* application or
framework!