Hiram, In order to be usable in large installations, the API should support querying multiple objects in one request. This is not about aggregation, it's about getting all the information in less HTTP requests. For instance, for queues, the API could support:
http://localhost:61680/virtual-hosts/localhost/queues/* -> return the list of all queue statuses and/or http://localhost:61680/virtual-hosts/localhost/queues/1,2,4 -> return the list of some queue statuses Again for scalability reasons, it would be useful to be able to control the amount of information retrieved. If one simply wants metrics information for thousands of queues, he could request: http://localhost:61680/virtual-hosts/localhost/queues/*/id,metrics to get only the "id" and "metrics" fields of all the queue status objects. FWIW, we currently heavily use these two features (multiple objects and given attributes) when querying ActiveMQ'a JMX using the excellent jmx4perl (http://search.cpan.org/~roland/jmx4perl). It seems that, by using the "json" suffix, one can get JSON data without having to change the HTTP Accept header. See http://localhost:61680/runtime/virtual-hosts/localhost.json versus http://localhost:61680/runtime/virtual-hosts/localhost If this trick is supported, it should be documented. The queue status can contain producers with: { "kind":"connection", "ref":"1", "label":"/127.0.0.1:52690" } What is this "ref"? Is it the "id" of the connection? IMHO, if yes, it should be renamed; if no, the "id" should be added to ease cross referencing. Cheers, Lionel
