[openstack-dev] [Glance][TC] Glance Functional API and Cross-project API Consistency

Hemanth Makkapati hemanth.makkapati at RACKSPACE.COM
Fri May 30 18:22:01 UTC 2014

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!

Hemanth Makkapati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/7ec93c94/attachment.html>

More information about the OpenStack-dev mailing list