[openstack-dev] [climate] Client and REST API versioning

Fuente, Pablo A pablo.a.fuente at intel.com
Thu May 1 13:50:56 UTC 2014


Hi,
	We recently implemented our V2 REST API, and at this moment we are
trying to get working our python client against this new version. For
this reason, we start a discussion about how the client will choose/set
the REST API version to use. BTW, we are not deprecating our V1 REST
API, so we need that our client still support it.
This are our discussions:

1 - Should the URL stored in Keystone service catalog have the version?
	In this case, our client will get the REST API URL from Keystone, parse
it, select the correct version of the client code and then start
performing requests. But if we choose this path, if a user of the client
decides to use the V1 REST API version using
--os-reservation-api-version, the client should strip the version of the
URL and then append the version that the user wants. The thing here is
that we are storing a version on a URL that we could not use in some
cases. In other words the version on the URL could be override.

2 - Should Climate store only one URL in Keystone catalog without
version?
	Here, the client, will know the default version to use, appending that
version to the service catalog version. When the client user request
another version, the client simply append that version to the end. The
cons of this option, is that if someone plan to use the REST API without
our client needs to know about how we handle the version. Here we can
provide /versions in order to tell how we are handling/naming versions.

3 - Should Climate store all the REST API URLs with the version at the
end and using versions in service types? e.g reservation and
reservationV2
	Here the client will get the version that needs querying the service
type by version. Seems that some projects do this, but for me seems that
this option is similar to 2, with the con that when Climate deprecate
V1, the only service type will be reservationV2, which sounds weird for
me.

We would like to get your feedback about this points (or new ones) in
order to get this implemented in the right way.

Pablo.
P.S. I hope that all the options in this email reflect correctly what we
discussed at Climate. If not, please add/clarify/remove what you want.


More information about the OpenStack-dev mailing list