openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

When you want to modify messages in a queue and also return those
that were modified. This is the atomic get/set needed by workers.

POST /account/queue?hide=60 HTTP/1.1

This will return all messages currently in /account/queue, but also
mark them as hidden for 60 seconds. This ensures only one worker was
able to see them, at least until the hide value expires.

-Eric

On Sat, Feb 19, 2011 at 02:13:49PM -0500, Mark Washenberger wrote:
> Can you give me some examples of the kinds of "update all messages in a queue" requests you're thinking of?
> 
> Thanks,
>  
> Mark
> 
> "Eric Day" <eday@xxxxxxxxxxxx> said:
> > 
> > I was wondering if someone would point out this discrepancy with
> > traditional REST semantics. :) The reason for the change is the following:
> > 
> > We need both an insert and update method for the queue and message
> > level. Some map well, but the "update all messages in a queue" (or the
> > set matching some criteria) is the oddball. A PUT .../queue doesn't
> > quite fit because we're not inserting or replacing a queue, we're
> > modifying all messages in it. I wanted to keep GET/HEAD read-only and
> > side-effect free, so I didn't want to overload those. Another option
> > was to use reserved words, possibly those prefixed with an underscore
> > (such as POST ../queue/_all), but this seemed unnecessary.
> > 
> > Instead, I propose using POST ../queue to mean modify the
> > queue (and possibly all messages in it). POST implies more of a
> > modify/append/process operation that PUT, which should strictly be
> > insert/replace. Using this form meant not using POST ../queue for
> > the traditional "insert but auto-generate ID" semantics, which is
> > why I used PUT instead. In some ways this is more consistent too,
> > since you are still inserting a message like PUT ../queue/message,
> > just without the id.
> > 
> 
>