GET queues/foo.bar?user=myUniqueId&timeout=5000This would activate my subscription to the queue foo.bar (or help to keep it alive) and return my own list of messages as an Atom feed that I am allowed to view and DELETE when I have consumed them.
This operation is idempotent and would work great with proxies and caches (assuming the right HTTP headers / ETags stuff) letting clients to keep GETing as often as they like. Though if you don't use the subscription for period of time, your subscription can go stale and timeout; any messages in your message collection could be removed.
The slightly smelly thing here is we need to either use cookies (such as for HTTP session handling with servlets) or use a custom session ID header in the URL to uniquely differentiate the subscriptions. Anyone got a better idea?
I guess we could demand that clients PUT/POST to get a new Location URL on which to GET their subscriptions; but this would require a custom REST client.
4 comments:
Hi James,
I would suggest to have a look on the amazon simple queue webservice. link: http://www.amazon.com/Simple-Queue-Service-home-page/b/ref=sc_fe_l_2?ie=UTF8&node=13584001&no=342430011&me=A36L942TSJ2AJA
It's to late for me right now to check out if they are doing what you're trying but may be you can get some ideas from this.
:)
I played with using HTTP authentication for something like that - if the client is sending credentials with every request you should be able to work out who they are, I'd have thought? Unless there are lots of users connecting from several places at once, that could get trickier.
I might of course be talking complete nonsense ;)
Thanks for the comments guys! Richard - yeah I took a look at Amazon's SQS and it looked kinda lo-rest like the current ActiveMQ REST support where GETs seem to consume messages right? Maybe I missed something, but it did seem a tad squiffy.
Michael - yeah I think that'd work great too; I just worry would intermediaries, proxies and caches get confused? e.g. if 2 different clients asked for the same URL would they handle the HTTP authentication stuff properly? I guess they should -so if thats the case then yeah thats a clean approach! :). I guess the unique user ID part of the URL could be optional and only used if you've some dodgy infrastructure...
I believe that the User ID allows scoping for the queues that you have visibility to.
Another comment would be that the Amazon service works. I have tried to drill down into ActiveMQ and have to say its incredibly cryptic to configure and use. I imagine for java experts with a long history of growing with the infrastructure being used, it's accessible but outside of that pedigree its just not accessible and very frustrating trying to locate examples for configuration and use especially with regard to REST style usage.
Post a Comment