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 ;)
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
