Open Stack

The semantics of whether GET / returns a 200 for a "list of versions" or a 300 "multiple choice" matter to me relatively little. I'm open to arguments in favor of either, though more people seem to be set on the idea of the 300. I do conceptually like the idea of versions as resources.

Where I think it gets messy is your suggestion that the version could be included in the URL *or* as a header. I think that's a dangerous proposition and we're better off sticking with a single canonical way of specifying a version. Putting the version in the URL structure is a pretty commonly accepted approach and (to the best of my knowledge) simplifies things on the routing end inside most of the projects.

All the best,

     - Gabriel

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Tuesday, May 28, 2013 7:41 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-tc] Proposal for API version
> discovery
> 
> On 05/28/2013 10:36 AM, Martyn Taylor wrote:
> > Hi all,
> >
> > I am currently looking at the Ironic API and was pointed towards the
> > etherpad here:
> > https://etherpad.openstack.org/api-version-discovery-proposal
> >
> > With regards to version discovery I wonder why do we not treat the API
> > and the Version simply like any other resource and have them
> > completely discoverable.  An example of how I originally had this is shown
> here:
> > https://gist.github.com/mtaylor/5663143//.  The example here uses the
> > same concepts across the whole of the API.  Therefore there is no need
> > to add in extra pieces such as response code 300 with some specific
> > document.  The API including versions are fully discoverable and treat
> > like any other resource.  To save complexity the API defaults to the
> > most recent version should a version not be specified in either the
> > MIME type or URL.
> >
> > What are your thoughts?  Is there some use case where this approach
> > will not work.
> 
> Seems eminently workable to me.
> 
> -jay
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev