Open Stack

Excerpts from Jay Pipes's message of 2013-08-06 10:34:30 -0700:
> 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.
> 

Agreed Jay. The successful extensible protocols like IMAP and SMTP are
merely allowing new arguments to existing fundamental functions.

HTTP allows different MIME types. There is no Content-Type extension to
the HTTP protocol. It also allows X-anything, but these are only ways
for a specific group to use the protocol as defined to communicate.

If there is something missing from keystone's model, it should be
added to the API. This does sound more like a cultural problem than a
technical one. Nobody should be afraid to add things to an API. I think
sometimes API writers are put into an ivory tower because they are also
held to higher standards for rigor and documentation. But we should all
be capable of applying that standard to ourselves at some point. 

It would help if we explicitly state that new API bits are encouraged,
rather than making the warm safe place "extension land".