> Elaborating on ii, this would also introduce a protocol to query linked
> objects, e.g. "GET /clusters/xxx/hosts" and "GET
> /datacenters/xxx/clusters". I'd go just one level deep. If you want to
> get all VMs in a datacenter, that's two queries.

Hi Geert,

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.

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.

GET /clusters?search=datacenterid=xxx

Or explicitly evaluated by the client (by walking the list returned from a generic GET /clusters).

Cheers,
Eoghan


On 13 September 2010 15:00, Geert Jansen <gjansen@redhat.com> wrote:
Hi,

currently we have

  GET /datacenters/xxx

  200 OK
  <data_center>
  ...
  </data_center>

versus

  GET /hosts/xxx

  200 OK
  <host>
  </host>

i.e. there's an inconsistency between the resource types and the URLs
here (datacenter vs data_center).

Another type of (apparent) inconsistency is this:

  GET /hosts/xxx/nics/yyy

  200 OK
  <host_nic>
  ...
  </host_nic>

But it isn't really if you make a distinction between two types of
sub-collections:

i. "Existentially dependent" subcollections. This is relationship with a
cardinality of 1...1 - 0...n. The resources in the sub-collection cannot
exist without the parent resource. An example is the NIC of a host.

ii. "Linked" subcollections. This is a relationship with a cardinality
of 0...1 (or 0...n) - 0...m, i.e. both exist indepdendent of each other.
For example, a cluster and its hosts.

My feeling is that for i. you need to qualify the resource type of the
subcollection because it can't exist by itself. So e.g. "host_nic" or
"hostnic". While for ii. there is no need for qualification as there
presumably is another top-level collection that maps all the resources.

Elaborating on ii, this would also introduce a protocol to query linked
objects, e.g. "GET /clusters/xxx/hosts" and "GET
/datacenters/xxx/clusters". I'd go just one level deep. If you want to
get all VMs in a datacenter, that's two queries.

If you guys like this, then the "attachments" in datacenters could be
changed by a subcollection "storagedomains" for a datacenter. Right now
you're using an association resource "attachment" which is a bit ugly in
my view. Association resources are a necessary evil when the association
itself has attributes, but that's not the case here. In this case i feel
they are just a complication.

Regards,
Geert
_______________________________________________
rhevm-api mailing list
rhevm-api@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhevm-api