"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Wednesday, May 26, 2004

Is this ReST?

Is this implementation of queueing a good example of the ReST approach?

Mark?

In particular I am wondering about the use of GET to dequeue an item. My understanding of how GET should behave is contrary to this. That is, two consecutive GET's with the same URL should have the same result, assuming no intervening POST, DELETE, or PUT that would affect that URL.

Corrections or corroborations appreciated.

9 comments:

Anonymous said...

Comments here:

http://www.dehora.net/journal/2004/05/activemq_restful_jms_sort_of.html

Bill

Mark Baker said...

My machine's offline today, but I responded last night; yah, the unsafe GET isn't such a hot idea.

And to add/respond to what Bill said, I'm finding that one often doesn't need TAKE semantics at all; just support indexing, e.g. /queue/?start=1&end=10, safe retrieval via GET, queueing of the documents for as long as you want/need to, flushing the old stuff after that point, and then returning 410 when asked to return a flushed document. Not totally general, but it's worked for me on a couple of occasions.

Anonymous said...

What about this:
GET /queue/head returns a 302 to /queue/msgs/0123ABCD
GET /queue/msgs/0123ABCD gets the message
DELETE /queue/msgs/0123ABCD does... guess what!

from there, GET /queue/head returns will 302 to another resource...

Anonymous said...

GET, GET, DELETE... interesting.

But how do you avoid multiple clients dequeuing the same thing?

Anonymous said...

> But how do you avoid multiple clients dequeuing the same thing?

What is the real problem: dequeuing or consuming? (I don't know much of JMS)
I mean:
- client B trying to DELETE a message already deleted by client A
- client B trying to GET a message deleted by client A while client B was managing the 302.

Patrick Logan said...

Is it legitimate for DELETE to respond the first time with a 200 and the entity deleted, but the next time with a 204 and no content?

I would intend this to mean the first DELETE dequeues and consumes in one method. The second just means "Yes, it's deleted, but you don't get the entity."

Anonymous said...

Interesting discussion on similar matters here:

http://www.xent.com/pipermail/fork/2001-August/002923.html

or

http://tinyurl.com/2engs

Anonymous said...

"No Charge Online Advertising Channels For Any Business"

Anonymous said...

Hey, you have a great blog here! I'm definitely going to bookmark you!

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.