Open Stack

On 08/06/2013 01:19 AM, Jamie Lennox wrote:
> Hi all,
>
> Partially in response to the trusts API review in keystoneclient
> (https://review.openstack.org/#/c/39899/ ) and my work on keystone API
> version discoverability (spell-check disagrees but I'm going to assume
> that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking
> about how we should be able to know what/if an extension is available. I
> even made a basic blueprint for how i think it should work:
> https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API.
>
> Is this intentional? I was starting to make a review to add it to
> identity-api but is there the intention that extensions should show up
> within the endpoint APIs? There is no reason it couldn't work that way
> and DELETE would just fail.

I would hope that extensions would *not* show up in the endpoints API.

Frankly, I'm not a fan of API extensions at all. I think they are silly 
and just promote an inconsistent and fractured user experience. I would 
highly prefer to just have a single API, versioned, with documentation 
online and in a versions/ resource that indicates what was changed, 
added, and deleted in each version.

If some vendor wants to provide some special API resource that naturally 
belongs in a related API -- for instance, trusts in the OpenStack 
Identity API -- then the new resource should simply be added to the one 
and only Identity API, the version of the API incremented, and on we go.

API extensions are more hassle than anything else. Let us promote 
standards, not endless extensibility at the expense of usability.

Best,
-jay