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