[openstack-dev] [api][nova][ironic] Microversion API HTTP header
sean at dague.net
Tue Jun 16 12:14:11 UTC 2015
On 06/16/2015 07:38 AM, Alex Xu wrote:
> 2015-06-16 18:57 GMT+08:00 Sean Dague <sean at dague.net
> <mailto:sean at dague.net>>:
> On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote:
> > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote:
> >> The original spec said that the HTTP header should contain the name of
> >> the service type returned by the Keystone service catalog (which is also
> >> the official name of the REST API). I don't understand why the spec was
> >> changed retroactively and why Nova has been changed to return
> >> X-OpenStack-Nova-API-Version instead of X-OpenStack-Compute-API-Version
> >> HTTP headers .
> > Given the disagreement evinced by the responses to this thread, let me
> > ask a question: Would there be any particular problem with using
> > "X-OpenStack-API-Version"?
> So, here is my concern with not having the project namespacing at all:
> Our expectation is that services are going to move towards real wsgi on
> their API instead of eventlet. Which is, hopefully, naturally going to
> give you things like this:
> GET api.server/compute/servers
> GET api.server/baremetal/chasis
> In such a world it will end up possibly confusing that
> OpenStack-API-Version 2.500 is returned from api.server/compute/servers,
> but OpenStack-API-Version 1.200 is returned from
> Client should get those url from keystone SC, that means client should
> know what he request to.
Sure, there is a lot of should in there though. But by removing a level
of explicitness in this we potentially introduce more confusion. The
goal of a good interface is not just to make it easy to use, but make it
hard to misuse. Being explicit about the service in the return header
will eliminate a class of errors where the client code got confused
about which service they were talking to (because to setup a VM with a
network in a neutron case you have to jump back and forth between Nova /
Neutron quite a bit).
This would provide an additional bit of signaling on that fact, which
will prevent a class of mistakes by API consumers.
More information about the OpenStack-dev