On 04/09/2010 07:20 PM, David Lutterkort wrote:
On Fri, 2010-04-09 at 10:09 +0100, Mark McLoughlin wrote:
> I'm starting to lean towards using URIs rather than GUIDs
>
> If you look at e.g.
>
> <vm href="http://{host}/vms/{guid}">
> <id>{guid}</id>
> <name>foo</name>
> </vm>
>
> then the URI serves as the true global identifier for the resource, the
> name serves as a human-readable identifier and the guid just seems like
> bloat
One of the reasons to include explicit URI's is so that we can later
change our mind about the URI structure of the server, without any ill
effects for the client. IOW, the URI is not stable enough to uniquely
identify the object for a long time.
I believe the top-level resource should have a <link rel="xxx" /> for
any resource type, right? Proper clients should then always use these
links to construct an URL. In that case it would be immaterial whether
you use GUIDs, or URIs. Given that, i'd actually prefer GUIDs as they
are shorter.
The above brings up another nitpicky issue: it would be nice if we
had a
simple way to use the same tag as the container of details for an
object, and as a reference for that object. There's also the slight
annoyance that it is generally easier to work with attribute values in a
DOM than with text nodes. So rather than the above, I'd suggest
<vm href="http://{host}/vms/{guid}" guid="{guid}"
name="foo">
... vm details ...
</vm>
Although if we want to support a JSON representation at some point in
addition to XML, using only text nodes would be easier. Mixing
attributes and text nodes would either give you a messy JSON
representation, or would introduce possible attribute/child naming
conflicts, depending on the mapping you choose to use.
Regards,
Geert
That can be used for both the container of VM details, and for
references to a VM (e.g., if you want to indicate which VM is using an
image) In that case, you'd write
<vm href="http://{host}/vms/{guid}" guid="{guid}"
name="foo"/>
and the client should have enough information to do some basic
processing (display a link to the VM details, cross-reference the VM
with other data it might be holding) without having to get the entire VM
details.
And no, that's not how deltacloud does it right now, though I think it
should.
David
--
Geert Jansen, Product Marketing Manager EMEA
Red Hat S.r.L. T: +39 348 1980079
Via Antonio da Recanate 1 E: gjansen(a)redhat.com
Milan 20124, Italy
Calculate your virtualization TCO at bit.ly/7CKhUm