[Openstack] Feedback on HTTP APIs

Jay Pipes jaypipes at gmail.com
Sat Jun 4 13:18:57 UTC 2011


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.
>




More information about the Openstack mailing list