Open Stack

Hello Hemanth,

Thanks for your summary, and raise it up in ML.

All of them are sensible to me, there is only one concern from
implementation perspective for me like to get folks notice.

If we follow 'POST /images/{image_id}/actions/{action_type}' approach,
I think we will hard to write common code on wsgi handling level (just
like current Nova approach did [0]) and keep router code be clear
(e.g. [1]) - don't need to add different rule to mapper for different
function/action be case by case. Rather, this way is straightforward
and I agreed those three reasons are understandable, but TBH probably
we need to think about it from implementation perspective a little
bit, follow this way we need to write more duplicated code for each
function/action on different code place/layer, e.g. [2] for route
layer. And for rate-limiting requirement, if we go 'POST
/servers/{server_id}/action {"type": "<action_type>", ...}' way,
probably we can do the limiting on wsgi/common layer easily as well,
of course we could design it later base on the selection.

[0] https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L1053
[1] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/server_start_stop.py#L43
[2] https://github.com/openstack/glance/blob/master/glance/api/v2/router.py#L81

zhiyan

On Sat, May 31, 2014 at 2: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. 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 (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
>