2015-06-16 18:57 GMT+08:00 Sean Dague <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. > > From an outsider looking in that seems very unexpected. > > So I think we still need service level namespacing on the version header > for clarity of understanding by application writers, by people filing > support tickets, and by people running these services. > > -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 >
__________________________________________________________________________ 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
