[openstack-dev] [Keystone] V3 Extensions Discoverability
jaypipes at gmail.com
Tue Aug 6 17:34:30 UTC 2013
On 08/06/2013 01:21 PM, David Chadwick wrote:
> On 06/08/2013 18:11, Jay Pipes wrote:
>> What SMTP, DNS and LDAP extensions are in use by systems that need to
>> interoperate in the same way that Keystone does? <-- This is a genuine
>> question, not sarcasm. I'm truly curious.
> Take SMTP for example. My Thunderbird client needs to know what
> authentication extensions are implemented by the POP3 server and SMTP
> server that it is talking to, in order to send and receive email in a
> secure manner.
> In the same way, once Keystone supports say federated login as an
> extension, a client will need to know if this extension is supported or
> not. If not, it wont be able to offer it to the end user. (It is not a
> sensible design for a client to send an extension protocol message to a
> server and get a 400 Bad Request response. This tells the client
> nothing. 501 Not Implemented might be a more informative response, but
> in this case the server has to know that an extension was requested and
> we have to document that this is the standard response to an
> unimplemented extension).
Ah, OK, so I think we're actually closer to one another than first
glance. So, I *entirely* agree that if API extensions are
available/supported by an API, then there should be an easy way to
discover those extensions -- /endpoints is perfectly fine.
I also agree that a *protocol* should have the flexibility, within its
bytestream construct, to extend its scope over time, *without needing to
change the underlying protocol*. So, for example, a protocol that leaves
itself some way of "growing" over time is, by nature, A Good Thing (tm).
However, I do *not* believe that resource additions to a REST-ful API
necessitate a new API "extension" that must be treated like something
that is fundamentally different from the existing resources published in
I do not believe the adding a /regions resource should require me to add
an API "extension" just to add the resource to the API. I believe we
should be able to propose the adding of the /regions resource, debate
it, and then add it to a v3.x Keystone API.
There isn't anything about a region resource that is fundamentally
different from some other resource managed by Keystone -- like domains
or endpoints -- and therefore I don't believe that adding a /regions
resource endpoint should require anything more than a bump in the
version of the API.
Hope this makes more sense,
p.s. Despite my opinion that /regions resource addition should not be an
extension, I'm still submitting a proposed API extension for it ;)
More information about the OpenStack-dev