Is this implementation of queueing a good example of the ReST approach? - Patrick Logan As a first cut the ActiveMQ guys have done a fair job; there is more they could do. In fairness, this is not so straighforward to get right, since modelling containers with URIs can be tricky. It's cool they're taking a principled approach. In particular I am wondering about the use of GET to dequeue an item If that's what they're doing, it's probably a bad idea (but I need to see the code to be sure). GET is for peeking rather than popping. Use POST/DELETE to dequeue. Otherwise if there is a cache between you and the origin server, you may get unexpected, silent, bugs when using GET insofar as a cache will interfere with expected JMS semantics. In the infrastructures I've worked with, this would cause issues. It helps enormously if each entity being sent into a queue is supplied its own URI- you do this by returning a URI in the Location header. We've used this in Propylon to manage reliable delivery over HTTP; it's very handy when it comes to tracking messages, browsing queues and building reconcilliation reports. This gets much trickier if the client has to have intimate knowledge of the URI structure- computing them instead of dealing with them as opaque strings ups the odds that what I throw together will be ActiveMQ specific (this would be a bit like having a local version of JMX). Aside from that, URI per sent item can scale by suppyling a naturally distributed data structure; in theory it's better to allow random access to items than demanding all clients synchronize access via the controller (queue/topic) URI. I would lose the timeout feature. If there are no messages simply return that information. Holding a reference via keep-alive is a hack to emulate API callbacks - don't go there ;) Finally, I wonder what they're doing around duplicate deliveries. The odds of that happening are much higher over HTTP than an inproc API call. I'll have to checkout the code to learn more - knowing Bob and James this will be a Maven build... [jay z: lucifer]...
Previous Topic
