Open Stack

Resources often have multiple representations, due to either media type versioning or differing underlying formats. A common convention is to create "variant" resources that support some specific representation(s) eg by putting a version number or file extension or both in the resouce identifier. 

I recommend using rel=bookmark for the permalink to the parent resource, not to variants. This is the most stable URI for long term linking to the underlying thing. It will survive changes in version and representation format.

For rel=self i dont care as much at excluding variants and it seems natural to put a versioned URI there when i have the bookmark next to it. 

On Jun 4, 2011, at 8:37 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:

> I think Jorge's "bookmark" links refer to an Atom permalink. Jorge, is
> that correct?
> 
> -jay
> 
> On Fri, Jun 3, 2011 at 11:34 AM, Thorsten von Eicken <tve at rightscale.com> wrote:
>> Really? The way I understand it, when I retrieve resource X I will get a
>> bookmark link for X. But when I retrieve resource Y that happens to have a
>> reference to X this references will not include the bookmark link for X, it
>> will just include X's URL. I'd then have to retrieve that URL, which would
>> get me that resource's bookmark link and then realize that this is actually
>> X which I already have. Or perhaps I'm not understanding the docs correctly?
>>     Thorsten
>> 
>> On 6/3/2011 5:39 AM, Jorge Williams wrote:
>> 
>> The whole idea behind the "bookmark" links is to give you the functionality
>> that you want -- that is a URL without a version number in it.  Looks like
>> the implementation hasn't yet added support for that, but it will.
>> -jOrGe W.
>> On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote:
>> 
>> We neither hate nor love UUIDs, but we like them when they provide value and
>> we also accept alternatives. What we do hate is ambiguity and in certain
>> cases UUIDs help.
>> 
>> Look at the hrefs returned in this sample resource and picture what you'd
>> store in your database as unique identifier to refer to each one:
>> {"server"=>
>>   {"name"=>"kd_test_3",
>>    "flavorRef"=>"http://5.5.2.2:8774/v1.1/flavors/3",
>>    "addresses"=>
>>     {"public"=>[], "private"=>[{"version"=>4, "addr"=>"5.5.2.5"}]},
>>    "metadata"=>{"v2"=>"d2", "4"=>"14", "5"=>"17"},
>>    "imageRef"=>"http://5.5.2.2:8774/v1.1/images/1",
>>    "id"=>26,
>>    "hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5",
>>    "links"=>
>>     [{"href"=>"http://5.5.2.2:8774/v1.1/servers/26", "rel"=>"self"},
>>      {"href"=>"http://5.5.2.2:8774/v1.1/servers/26",
>>       "rel"=>"bookmark",
>>       "type"=>"application/json"
>>      },
>>      {"href"=>"http://5.5.2.2:8774/v1.1/servers/26",
>>       "rel"=>"bookmark",
>>       "type"=>"application/xml"
>>      }
>>     ],
>>    "status"=>"ACTIVE"
>>   }
>> }
>> Are the hostnames significant? Are the port numbers significant? Are the
>> version IDs significant? Is the next URI component significant? Is the
>> integer ID significant? Mhhh, maybe it's obvious to the OpenStack
>> implementers, but it leaves quite some room for error for all the users out
>> there. We end up having to write a little algorithm that throws away the
>> hostname and port, then throws away the version number if there is one -- it
>> really should NOT be part of the URL! -- then looks at the next path
>> component to decide whether its the resource type and whether the path
>> component after that is the resource id, or whether there is further nesting
>> of path components. Then we can assemble a unique ID and see whether we know
>> about that resource or need to fetch it. It would be really nice to have a
>> UUID attribute that eliminates this guesswork and we like UUIDs that start
>> with a type-specific prefix, such as inst-12345 or img-12345.
>> 
>> Our recommendation:
>>  - option 1: use canonical hrefs that can be used as unique IDs, which means
>> without host/port and without version number
>>  - option 2: use a unique ID with a type prefix and include that as
>> attribute in hrefs, we like small IDs, but we don't care that much
>> 
>> WRT UUIDs, we try to use integer IDs when we can easily generate them
>> centrally, but switch to UUIDs when we need to distribute the ID generation
>> and we keep them as short as practical.
>> 
>> Thanks much!
>> Thorsten - CTO RightScale
>> 
>> 
>> On 6/2/2011 12:40 PM, Jay Pipes wrote:
>> 
>> On Thu, Jun 2, 2011 at 1:18 PM, George Reese <george.reese at enstratus.com>
>> wrote:
>> 
>> I hate UUIDs with a passion.
>> 
>> * They are text fields, which means slower database indexes
>> 
>> Text fields are stored on disk/in memory as bytes the same as any
>> integer. It's that the number of bytes needed to store it is greater,
>> resulting in larger indexes and more bytes to store the keys. But, as
>> Jorge mentioned, some databases have native support for large-integer
>> types like UUIDs.
>> 
>> * They are completely user-unfriendly. The whole "copy and paste" argument
>> borders on silliness
>> 
>> Yes, it's not easy to remember UUIDs. That's why virtually every
>> resource has some other way of identifying themselves. Typically, this
>> is a name attribute, though not all resources enforce uniqueness on
>> the name attribute, thus the need for a unique identifier.
>> 
>> I don't see people manually looking up resources based on UUIDs. I see
>> *machines* manually looking up resources based on UUIDs, and humans
>> looking up resources by, say, name, or (name, tenant_id) or (name,
>> user_id), etc.
>> 
>> * And uniqueness across regions for "share nothing" can be managed with a
>> variety of alternative options without resorting to the ugliness that is
>> UUIDs
>> 
>> Like URIs? I don't know of any other options that would work. Please
>> let us know what you think about in this respect.
>> 
>> -jay
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> Confidentiality Notice: This e-mail message (including any attached or
>> embedded documents) is intended for the exclusive and confidential use of
>> the
>> individual or entity to which this message is addressed, and unless
>> otherwise
>> expressly indicated, is confidential and privileged information of
>> Rackspace.
>> Any dissemination, distribution or copying of the enclosed material is
>> prohibited.
>> If you receive this transmission in error, please notify us immediately by
>> e-mail
>> at abuse at rackspace.com, and delete the original message.
>> Your cooperation is appreciated.
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com, and delete the original message. 
Your cooperation is appreciated.