Open Stack

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 
the API.

Por ejemplo,

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,
-jay

p.s. Despite my opinion that /regions resource addition should not be an 
extension, I'm still submitting a proposed API extension for it ;)