On 09/16/2010 05:37 PM, Eoghan Glynn wrote:
As it happens, we were discussing a similar point this morning in
the
context of whether we should support bidirectional navigation between
VMs and VM pools (currently we expose the individual pool associated
with a particular VM, but not the set of VMs contained by a particular
pool).
So while it seems tempting to model all sorts of associations, I'd have
a concern that this would get out of hand and unnecessarily complicate
the API, when the same information can always be determined indirectly.
My feeling is that we should restrict it to case where the association
is very strong, of the "existential" variety as you put it.
In my view associations are as real a part of the API as the resources
itself, and therefore it would make sense to model them.
For example, the primary purpose of a VM pool is to provide a set of
VMs
cut from the same cloth. So in that case, I would see it as being
justifiable to model the association directly via a sub-collection.
However, there are weaker associations that could instead be better
modeled via a query, e.g.
The pool -> VM relationship is a bit particular. You cannot delete a
pool when it has VMs in it, so it's required for those VMs to exist. But
in general a VM can exist outside a pool. So if we only want to model
existentially dependent relationships then this one is somewhere in the
middle.
GET /clusters?search=datacenterid=xxx
Or explicitly evaluated by the client (by walking the list returned from
a generic GET /clusters).
Actually this search doesn't work (but it can be made to work - see
ticket #80). In my view using a query (or walking the list) is not the
preferred way to look for related objects, as this way you don't model
the relationship. For example, suppose there's 10 attributes that you
could search on. Only a few of those would indicate a relationship, and
the others would be data attributes. You have no real way to distinguish
what is what.
Regards,
Geert