I will provide a little more context for the TC audience. I asked Hemanth to tag this message [TC] because at the Juno summit in the cross-project track there was discussion of cross-project api consistency [1]. The main outcome of that meeting was that "TC should recommend API conventions via openstack/governance as defined by those interested in the community". If you dig further into that etherpad, I believe there is a writeup of "actions" but I don't think we actually found time to hit that point during the discussion.
Thanks! [1] - https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis On Fri, May 30, 2014 at 11:22 AM, Hemanth Makkapati < [email protected]> wrote: > Hello All, > I'm writing to notify you of the approach the Glance community has decided > to take for doing functional API. Also, I'm writing to solicit your > feedback on this approach in the light of cross-project API consistency. > > At the Atlanta Summit, the Glance team has discussed introducing > functional API in Glance so as to be able to expose operations/actions that > do not naturally fit into the CRUD-style. A few approaches are proposed and > discussed here > <https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api>. > We have all converged on the approach to include 'action' and action type > in the URL. For instance, 'POST /images/{image_id}/actions/{action_type}'. > > However, this is different from the way Nova does actions. Nova includes > action type in the payload. For instance, 'POST /servers/{server_id}/action > {"type": "<action_type>", ...}'. At this point, we hit a cross-project API > consistency issue mentioned here > <https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis> > (under the heading 'How to act on resource - cloud perform on resources'). > Though we are differing from the way Nova does actions and hence another > source of cross-project API inconsistency , we have a few reasons to > believe that Glance's way is helpful in certain ways. > > > The reasons are as following: > 1. Discoverability of operations. It'll be easier to expose permitted > actions through schemas a json home document living at > /images/{image_id}/actions/. > 2. More conducive for rate-limiting. It'll be easier to rate-limit actions > in different ways if the action type is available in the URL. > 3. Makes more sense for functional actions that don't require a request > body (e.g., image deactivation). > > At this point we are curious to see if the API conventions group believes > this is a valid and reasonable approach. > > Any feedback is much appreciated. Thank you! > > Regards, > Hemanth Makkapati > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
