(generic client)
> I guess the follow-up question is this: what value does this provide?
Think of the case that one is using a workflow engine. It doesn't know
anything about your technology but solely that it is http-based, REST and
that "add item", "pay" and "ship" are the link roles to look for. My
"generic client" is the intermediary glue to allows the workflow engine to
concentrate on the business process. If you will start putting links in
self-invented headers for example, this possibility would be broken, as YOU
(as the vendor of the service) must know how to tell MY generic client that
there is such a self-invented header. But as neither do I know about the
existence of your service (I received your URI possible from another server
without further information and just followed the link, just a man is
surfing the web!) nor do YOU know about the existence, technology or
programming language of my generic client or the workflow engine driving it!
So if your system and mine want to work together, there is no other choice
than accepting not to do any "stange" things but just to have headers found
in "intuitive" places: The entity and the "Link" header. Inventing anything
else is impossible to get understood by foreing clients! So the idea that
you are writing a special client for a special service is not a solution for
all types of EAI scenarios.