[openstack-dev] [Keystone] V3 Extensions Discoverability
jaypipes at gmail.com
Tue Aug 6 13:46:12 UTC 2013
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.
More information about the OpenStack-dev