<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 11:54 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 05/30/2014 02:22 PM, Hemanth Makkapati wrote:<br>
> Hello All,<br>
> I'm writing to notify you of the approach the Glance community has<br>
> decided to take for doing functional API.  Also, I'm writing to solicit<br>
> your feedback on this approach in the light of cross-project API<br>
> consistency.<br>
><br>
> At the Atlanta Summit, the Glance team has discussed introducing<br>
> functional API in Glance so as to be able to expose operations/actions<br>
> that do not naturally fit into the CRUD-style. A few approaches are<br>
> proposed and discussed here<br>
> <<a href="https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api" target="_blank">https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api</a>>.<br>
> We have all converged on the approach to include 'action' and action<br>
> type in the URL. For instance, 'POST<br>
> /images/{image_id}/actions/{action_type}'.<br>
><br>
> However, this is different from the way Nova does actions. Nova includes<br>
> action type in the payload. For instance, 'POST<br>
> /servers/{server_id}/action {"type": "<action_type>", ...}'. At this<br>
> point, we hit a cross-project API consistency issue mentioned here<br>
> <<a href="https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis" target="_blank">https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis</a>><br>
> (under the heading 'How to act on resource - cloud perform on<br>
> resources'). Though we are differing from the way Nova does actions and<br>
> hence another source of cross-project API inconsistency , we have a few<br>
> reasons to believe that Glance's way is helpful in certain ways.<br>
><br>
> The reasons are as following:<br>
> 1. Discoverability of operations.  It'll be easier to expose permitted<br>
> actions through schemas a json home document living at<br>
> /images/{image_id}/actions/.<br>
> 2. More conducive for rate-limiting. It'll be easier to rate-limit<br>
> 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<br>
> body (e.g., image deactivation).<br>
><br>
> At this point we are curious to see if the API conventions group<br>
> believes this is a valid and reasonable approach.<br>
> Any feedback is much appreciated. Thank you!<br>
<br>
Honestly, I like POST /images/{image_id}/actions/{action_type} much<br>
better than ACTION being embedded in the body (the way nova currently<br>
does it), for the simple reason of reading request logs:<br></blockquote><div><br></div><div>I agree that not including the action type in the POST body is much nicer and easier to read in logs, etc.<br><br></div><div>That said, I prefer to have resources actually be things that the software creates. An action isn't created. It is performed.<br>
<br></div><div>I would prefer to replace the term "action(s)" with the term "task(s)", as is proposed for Nova [1].<br><br></div><div>Then, I'd be happy as a pig in, well, you know.<br><br></div><div>
Best,<br></div><div>-jay<br></div></div><br>[1] <a href="https://review.openstack.org/#/c/86938/">https://review.openstack.org/#/c/86938/</a><br></div></div>