Description of problem:
The <snapshot> XML that you receive from the API is currently looks like:
<snapshot href="/api/vms/086b5092-71d6-4cfa-b73d-d32bff2890cb/snapshots/93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783" id="93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783">
<description>1</description>
<type>regular</type>
<vm id="086b5092-71d6-4cfa-b73d-d32bff2890cb">
<name>elad2-3</name>
<description/>
<link href="/api/vms/086b5092-71d6-4cfa-b73d-d32bff2890cb/snapshots/93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783/cdroms" rel="cdroms"/>
<link href="/api/vms/086b5092-71d6-4cfa-b73d-d32bff2890cb/snapshots/93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783/disks" rel="disks"/>
<link href="/api/vms/086b5092-71d6-4cfa-b73d-d32bff2890cb/snapshots/93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783/nics" rel="nics"/>
<type>server</type>
... *more stuff not relevant for this bug*
</vm>
</snapshot>
The links points directly with the URL to the collections (i.e. cdroms, disks, nics) being under the snapshot object, which is not consistence with the xml object which is <snapshot>....<vm><link ....=/collection/></vm></snapshot>.
Version-Release number of selected component (if applicable):
rhevm-3.4.0-0.3.master.el6ev.noarch
rhevm-restapi-3.4.0-0.3.master.el6ev.noarch
How reproducible:
100%
Steps to Reproduce:
1. Create a snapshot of vm with disk
2. from REST api go to: /api/vms/<vm_id>/snapshots/<snapshot_id>/
3. The links are located under <vm> ... </vm>
Actual results:
The links are found under vm: <snapshot>....<vm><link ....=/collection/></vm></snapshot>.
And a link to disks collection (for example) is:
<link href="/api/vms/086b5092-71d6-4cfa-b73d-d32bff2890cb/snapshots/93d8fc6e-bdcf-4726-b1c5-8c5c24f8a783/disks" rel="disks"/>
which is not consistence with the xml object
Expected results:
All links should be directly under snapshot and not under vm
Additional info:
Comment 2Michael Pasternak
2014-06-23 13:05:42 UTC
i don't think this is a bug, URI structure does not have to be 1:1 with
object representation,
(also there is no much sense in mentioning vm in url once again cause it already represented by 086b5092-71d6-4cfa-b73d-d32bff2890cb identifier)
as long as representation self descriptive and let accessing related resources
via links it holds, it's okay from the REST PoV,
so bottom line IMHO it's not a bug.
Verified on:
ovirt-engine-3.5.0-0.0.master.20140715172116.git4687dc1.el6.noarch
ovirt-engine-restapi-3.5.0-0.0.master.20140715172116.git4687dc1.el6.noarch