On Wed, 24 Sep 2014 09:04:51 -0400 Jay Pipes <jaypi...@gmail.com> wrote:
> On 09/24/2014 05:26 AM, Kenichi Oomichi wrote: > >> -----Original Message----- > >> From: Jay Pipes [mailto:jaypi...@gmail.com] > >> Sent: Wednesday, September 24, 2014 12:47 AM > >> To: openstack-dev@lists.openstack.org > >> Subject: Re: [openstack-dev] [Nova] Some ideas for micro-version > >> implementation > >> > >> On 09/22/2014 04:27 PM, Brant Knudson wrote: > >>> On Fri, Sep 19, 2014 at 1:39 AM, Alex Xu <x...@linux.vnet.ibm.com > >>> <mailto:x...@linux.vnet.ibm.com>> wrote: > >>> > >>> Close to Kilo, it is time to think about what's next for > >>> nova API. In Kilo, we > >>> will continue develop the important feature micro-version. > >>> > >>> In previous v2 on v3 propose, it's include some > >>> implementations can be used for micro-version. > >>> > >>> (https://review.openstack.org/__#/c/84695/19/specs/juno/v2-on-__v3-api.rst > >>> > >>> <https://review.openstack.org/#/c/84695/19/specs/juno/v2-on-v3-api.rst>) > >>> But finally, those implementations was considered too > >>> complex. > >>> > >>> So I'm try to find out more simple implementation and > >>> solution for micro-version. > >>> > >>> I wrote down some ideas as blog post at: > >>> http://soulxu.github.io/blog/__2014/09/12/one-option-for-__nova-api/ > >>> <http://soulxu.github.io/blog/2014/09/12/one-option-for-nova-api/> > >>> > >>> And for those ideas also already done some POC, you can find > >>> out in the blog post. > >>> > >>> As discussion in the Nova API meeting, we want to bring it > >>> up to mail-list to > >>> discussion. Hope we can get more idea and option from all > >>> developers. > >>> > >>> We will appreciate for any comment and suggestion! > >>> > >>> Thanks > >>> Alex > >>> > >>> > >>> > >>> Did you consider JSON Home[1] for this? For Juno we've got JSON > >>> Home support in Keystone for Identity v3 (Zaqar was using it > >>> already). We weren't planning to use it for microversioning since > >>> we weren't planning on doing microversioning, but I think JSON > >>> Home could be used for this purpose. > >>> > >>> Using JSON Home, you'd have relationships that include the > >>> version, then the client can check the JSON Home document to see > >>> if the server has support for the relationship the client wants > >>> to use. > >>> > >>> [1] http://tools.ietf.org/html/draft-nottingham-json-home-03 > >> > >> ++ I used JSON-Home extensively in the Compute API blueprint I put > >> together a few months ago: > >> > >> http://docs.oscomputevnext.apiary.io/ > > > > vNext seems an interesting idea, I thought the implementation way > > for Nova a little. "API Route Discoverability" is a nice design, > > but a root "/" URL will conflict on current "list versions" API. > > Maybe there would be a workaround. > > Completely agreed, Ken'ichi. The "root" URL that returns the > JSON-Home doc in the vNext API is actually *after* the version in the > URI, though... > > So, the JSON-Home doc would be returned from: > > http://compute.example.com/vNext/ > > Of course, replacing "vNext" with "v4" or "v42" or whatever the > "next" major version of the API would be. The real root would still > return the versions list as it exists today, with a 302 Multiple > Choice. Why have a version in the url at all? With microversions it doesn't really make any sense and would just cause more churn for app developers. Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
