<div dir="ltr">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.<div>
<br></div><div>Thanks!<br><div><br></div><div><br></div><div>[1] - <a href="https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis">https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis</a></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 11:22 AM, Hemanth Makkapati <span dir="ltr"><<a href="mailto:hemanth.makkapati@rackspace.com" target="_blank">hemanth.makkapati@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><font color="black" face="Tahoma"><span style="font-size:10pt" dir="ltr"><div class="">Hello All,<br>
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.<br>

<br>
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
<a href="https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api" target="_blank">
here</a>. 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}'.<br>
<br></div>
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
<a href="https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis" target="_blank">
here</a> (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.<div class=""><br>
<br>
The reasons are as following:<br>
1. Discoverability of operations.  It'll be easier to expose permitted actions through schemas a json home document living at /images/{image_id}/actions/.<br>
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.<br>
3. Makes more sense for functional actions that don't require a request body (e.g., image deactivation).<br>
<br></div>
At this point we are curious to see if the API conventions group believes this is a valid and reasonable approach.<div class=""><br>
Any feedback is much appreciated. Thank you!<br>
<br></div>
Regards,<br>
Hemanth Makkapati<br>
</span></font></div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>