Open Stack

Le 1 mai 2014 19:11, "Dolph Mathews" <dolph.mathews at gmail.com> a écrit :
>
>
> On Thu, May 1, 2014 at 8:50 AM, Fuente, Pablo A <pablo.a.fuente at intel.com>
wrote:
>>
>> 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.
>
>
> No - avoid bloating the service catalog with redundant data.
>
>>
>>
>> 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.
>
>
> This is by far the best option you've presented, but the client should
also perform discovery on the endpoint as specified in the catalog, without
trying to arbitrarily manipulate it first. If you return the versioning
information in response to / instead of /versions then you're not forcing
clients to have prior knowledge of an arbitrary path.

I agree with Dolph, that's the best way. If you look at the first version I
wrote for the API, it was planned to be served at root path. I haven't
implemented yet the discovery feature in the API, but that's something
quick to do, as Pecan is the default WSGI app for root.

-Sylvain

>
>>
>>
>> 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.
>
>
> No - a different version of a service does not represent a different type
of service. Similar to option 1, this also bloats the service catalog
unnecessarily.
>
>>
>>
>> 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.
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/08050401/attachment.html>