Open Stack

On Jan 29, 2013, at 9:37 AM, Jay Pipes wrote:

I think versionList is pointless, as you mention above the proper way of
handling this is a 300 Multiple Choice response on the base endpoint.
The endpoints themselves should be the source of truth about what
versions of an API they expose or support. Keystone, IMHO, should merely
be a directory of endpoints/services, not a directory of endpoints and
API versions on an endpoint.


I'm sorry there seems to be some confusion about what the attributes are for.  I should have been more specific....

The purpose is *not* to have all version metadata reside in keystone. Keystone is simply worried about Endpoints as you've described.  These attributes are part of an endpoint and they   simply  provide two links to the service itself. One link provides a list of available versions for that service at that endpoint.  The other lists details about the version described by the endpoint.  Thad metadata likes in the service not in keystone.  The links allow a client  a means of introspecting what's available.  300 Multiple Choice response is fine -- and we should support that too, but sometimes you want to know what's out there without having to issue a working request to the service (create a server) -- this is useful especially if you need to create a UI, for example.  You shouldn't have to create a server to figure out if you support version X, and therefore should add version X features into the UI.

-jOrGe W.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130129/acbfb33e/attachment.html>