Juan Hernandez has posted comments on this change.
Change subject: restapi: Scan collections on model when adding links
......................................................................
Patch Set 2:
Usually when a resource has a set of references to other resources this is
represented in the RESTAPI as a subcollection. So you have the original
resource:
GET /whatevers/{whatever:id}
<whatever id="...">
...
</whatever>
And then the subcollection:
GET /whatevers/{whatever:id}/networks
<networks>
<network id="..." href="...">
...
</network>
...
</networks>
The relationship between both is specified with an explicit link within the
resource representation:
GET /whatevers/{whatever:id}
<whatever id="...">
<link href="/whatever/{whatever:id}/networks" rel="networks"/>
...
</whatever>
I this scenario we don't need to add links to elements inside collections
nested inside the resource representation, because we don't have such nested
collections. I mean, we usually don't have something like this:
GET /whatever/{whatever:id}
<whatever id="...">
<networks>
<network id="..." href="...">
...
</network>
<network id="..." href="...">
...
</network>
</networks>
...
</whatever>
This way we do things is very important when it comes to add/remove/update a
particular member of this sub collection. I prefer if we continue doing it this
way. Even if we think that it isn't necessary to add/remove/update members I
would prefer to have a sub collection, a read only one.
My understanding is that having this collection may complicate creating a new
"whatever" object, as it would require the caller to do at least two
operations: create the "whatever" and then create the nested "networks". But
this is not completely true, as you can accept the nested collection in the
POST operation used to create the "whatever" object:
POST /whatevers
<whatever>
<networks>
<network id="..."/>
<network id="..."/>
...
</networks>
</whatever>
Does this make sense?
--
To view, visit http://gerrit.ovirt.org/26953
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I148b9b690fad95b5ec0503beba254c1066a797fe
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Sergey Gotliv <[email protected]>
Gerrit-Reviewer: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Sergey Gotliv <[email protected]>
Gerrit-Reviewer: [email protected]
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: No
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
