On 06/16/2015 07:38 AM, Alex Xu wrote: > > > 2015-06-16 18:57 GMT+08:00 Sean Dague <s...@dague.net > <mailto:s...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev