[openstack-dev] [keystone] endpoint versioning in API v3
jorge.williams at rackspace.com
Mon Jan 28 20:54:33 UTC 2013
The idea is that services can provide two resources:
1. One resource provides a list of available versions of the service (Versions List)
2. One resource provides details about a particular version (Version Details)
The idea was that the service catalog can give you a couple of pointers where you can get metadata about the service. For example: is it in Beta? When was it last updated? Are any new versions available? Where can I find documentation? etc.
For the nova API see examples 3.26 - 3.33 here: http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html
On Jan 28, 2013, at 2:21 PM, Dolph Mathews wrote:
I just noticed that we overlooked/forgot a feature from the v2 serviceCatalog API which includes the following attributes on each endpoint:
I never completely understood the intended use case for these attributes... e.g. if you can ask the remote service for a 'version list' then why does keystone need to redundantly identify the API version of the endpoint and enumerate options for each API version? I don't think you should have to revise your service catalog to roll out a new API version, either. IMO, clients should (ideally) start with an unversioned endpoint, receive a 300 Multiple Choice response, and select a compatible/acceptable versioned endpoint before proceeding.
Is anyone using this feature in v2 and want to see it carried forward to v3?
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev