Open Stack

So, there are two issues that are clearly tied into doing version and extension/capability discovery:

1. What *is* an extension? This has come up in both Cinder and Nova recently, and there's ongoing community and TC discussion trying to nail that down. The closest consensus so far seems to be that an extension is anything which defines an "optional" part of the API which can be enabled/disabled and that those must be discoverable via the /extensions part of the API. This definition is not final, but let's go with that as a working definition for the purposes of this proposal.

2. Project/Tenant IDs in URLs are inconsistent across projects and provide a modest complication in stripping the service catalog down to root service endpoints. I think the issue can easily be addressed in the clients for those projects whose URL structures deviate from the simplest common format, but it might be worth revisiting the value of those Project URLs. The two arguments can be summarized as "being truly RESTful" and "caching".

The RESTful argument rests on the idea that in "true" REST the response from a particular URL can't vary based on context. Therefore project/tenant IDs can't be context, they have to be part of the URL. The argument is valid, but IMHO pedantic. Many well-known modern "RESTful" APIs eschew that notion and allow variance by context. It's an eminently pragmatic decision, and OpenStack is currently in a mixed state, so I think we should settle it one way or the other as a community.

Caching-wise, it allows for the "dumbest" type of URL-based caching. But almost every modern caching system can respect Vary headers to support caching based on the auth token (which is what we're actually varying on, not the project ID... so the RESTful thing is already invalid...). All in all caching is really a non issue.

Thoughts on those points?

    - Gabriel

> -----Original Message-----
> From: Kurt Griffiths [mailto:kurt.griffiths at rackspace.com]
> Sent: Thursday, May 02, 2013 7:08 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [openstack-tc] Proposal for API version
> discovery
> 
> > * We add a 'GET /capabilities' which returns a document describing
> >    which features this endpoints support - a feature could be optional
> >    because it was added in a new version or because not all
> >    deployments would be configured with it enabled. This would allow
> >    clients to be able to query for features, rather than having a
> >    hard-coded understanding of which minor versions support which
> >    features.
> 
> +1
> 
> We are planning on experimenting with the nascent home document
> standards for Marconi rather than trying to invent our own:
> 
> http://tools.ietf.org/html/draft-nottingham-json-home-02
> 
> http://datatracker.ietf.org/doc/draft-wilde-home-xml/
> 
> 
> ===
> 
> Kurt | irc/twitter: kgriffs
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev