On 06/11/2014 02:34 AM, Mark Washenberger wrote:
I think the tasks stuff is something different, though. A task is a
(potentially) long-running operation. So it would be possible for an
action to result in the creation of a task. As the proposal stands
today, the actions we've been looking at are an alternative to the
document-oriented PATCH HTTP verb. There was nearly unanimous consensus
that we found "POST /resources/actions/verb {inputs to verb}" to be a
more expressive and intuitive way of accomplishing some workflows than
trying to use JSON-PATCH documents.

Why do tasks necessarily mean the operation is long-running? As mentioned before to Brian R, just have the deactivation action be a task. There's no need to create a new faux-resource called 'action', IMO...

Best,
-jay

On Tue, Jun 10, 2014 at 4:15 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:

    On Wed, Jun 4, 2014 at 11:54 AM, Sean Dague <s...@dague.net
    <mailto:s...@dague.net>> wrote:

        On 05/30/2014 02:22 PM, 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
         >
        
<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!

        Honestly, I like POST /images/{image_id}/actions/{action_type} much
        better than ACTION being embedded in the body (the way nova
        currently
        does it), for the simple reason of reading request logs:


    I agree that not including the action type in the POST body is much
    nicer and easier to read in logs, etc.

    That said, I prefer to have resources actually be things that the
    software creates. An action isn't created. It is performed.

    I would prefer to replace the term "action(s)" with the term
    "task(s)", as is proposed for Nova [1].

    Then, I'd be happy as a pig in, well, you know.

    Best,
    -jay

    [1] https://review.openstack.org/#/c/86938/

    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to