On Thu, 2010-04-08 at 09:45 +0100, Eoghan Glynn wrote:
> Perhaps doing both might make sense - include the URIs in the response
> body and header?
For the top-level GET, yeah.
For VM retrieval, that would also be fine where there's only a single
VM in the response, say the return from "GET /vms/XXXX".
But where there's more than one VM returned, say a collection
containing search results, then the links would be specific to each
individual VM so it seems cleaner to just inline in the corresponding
VM element to give the correct context. Similarly for any other
resource collection that can be retrieved en masse.
I guess the same context could be somehow shoehorned in the
per-response Link headers (maybe embedded in the rel attribute), but
that could get a bit messy.
So the Link header seems to work best in the special case where the
URIs provided are "global" to the response, which will only hold for a
subset of this API.
Just for archival purposes - Eoghan pointed out p124 of RESTful Java
where bburke talks about this
Our reading of "I like to use Atom links for data aggregation and Link
headers for everything else" basically jives with what Eoghan is saying
here
So, IMHO, we should always include <link>s in the <vm> description but
only also include them as Link: headers when we're returning a single
VM, not a collection of VMs
i.e. "GET /vms/{id}" should have both Link: headers and <link>s,
wherease "GET /vms" should only have <link>s
Cheers,
Mark.