← Back to team overview

openstack team mailing list archive

Re: Queue Service, next steps


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.


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.
> >