Open Stack

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 [4].
>     >
>     > 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
>     api.server/baremetal/chasis.
> 
> 
> 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.

	-Sean

-- 
Sean Dague
http://dague.net