Simply put, business resources should be “one step back” from HTTP IMHO. When you send non-idempotent messages to a resource (e.g. POST/PUT), you send them to its inward bound, asynch message queue. You do not directly interact with the business resource.
Interesting position on queues, but I think you’ll eventually run into problems doing that … though clearly not major problems, otherwise you’d have discovered them already 8-).
Whenever I want to do the queue thing, I use two resources; the “business resource”, and “the inbound message queue for that business resource” (though of course, as a separate resource, it need not be used only for the business resource). I then subscribe the business resource to the queue, such that messages POSTed to the queue also are forwarded to the business resource. FWIW, I’ve been using mod_pubsub recently to manage the queue resource (as a topic maintained by its router) in some work I’m doing on the side.
The problems I see with the approach Sean describes are a result of it not acknowledging that the queue is a separate resource than the business resource, as this can lead to ambiguities. For example, what can be expected from a GET on the URI; a representation of the state of the business resource, or a representation of the state of the queue?
That structure I described is probably a useful Web idiom to write up… I’ll put it on my todo list. 8-)
P.S. I assume you wanted to say “non-safe” there, since PUT is idempotent.