On Fri, 2014-05-30 at 18:22 +0000, Hemanth Makkapati 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.
It's obviously preferable if new APIs follow conventions established by
existing APIs, but I think you've laid out pretty compelling rationale
for not following Nova's lead on this.
The question is whether Nova should plan on adopting this approach in a
future version of its API?
Mark.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
