Open Stack

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 <
hemanth.makkapati at rackspace.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/0cd527dd/attachment.html>