[openstack-dev] [api] service type vs. project name for use in headers
sean at dague.net
Mon Feb 1 14:24:55 UTC 2016
On 02/01/2016 09:13 AM, Brant Knudson wrote:
> On Wed, Jan 27, 2016 at 1:47 PM, michael mccune <msm at redhat.com
> <mailto:msm at redhat.com>> wrote:
> hi all,
> there have been a few reviews recently where the issue of service
> type versus project name have come up for use in the headers. as
> usual this conversation can get quite murky as there are several
> good examples where service type alone is not sufficient (for
> example if a service exposes several api controllers), and as has
> been pointed out project name can also be problematic (for example
> projects can change name).
> i'm curious if we could come to a consensus regarding the use of
> service type *or* project name for headers. i propose leaving the
> ultimate decision up to the projects involved to choose the most
> appropriate identifier for their custom headers.
> i am not convinced that we would ever need to have a standard on how
> these names are chosen for the header values, or if we would even
> need to have header names that could be deduced. for me, it would be
> much better for the projects use an identifier that makes sense to
> them, *and* for each project to have good api documentation.
> so, instead of using examples where we have header names like
> "OpenStack-Some-[SERVICE_TYPE]-Header", maybe we should suggest
> "OpenStack-Some-[SERVICE_TYPE or PROJECT_NAME]-Header" as our guideline.
> for reference, here are the current reviews that are circling around
> this issue:
> and one that has already been merged:
> Why does the service type or name need to be in the header at all? The
> request goes to a specific service so the server and client already know
> the service type or name. - Brant
Sometimes it does. But some times we have one service return ref links
to another url, which might be in a different service.
A very common instance is Nova returning links to glance images, which
include a glance image url directly.
Keeping that header in place is extremely helpful from a clarity
perspective instead of using heuristics of manually splitting apart urls
and guessing. That second approach is one of the reasons the devstack
keystone v3 patches keep being disruptive.
More information about the OpenStack-dev