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