[rabbitmq-discuss] Document HTTP API responses?

[Brian K. Jones]

On Friday, June 3, 2011 at 6:02 AM, Simon MacMullen wrote:

> On 02/06/11 21:35, Brian K. Jones wrote:
> > I'm testing a Python module that provides an easy way to work with the
> > RabbitMQ Management HTTP API. I'm testing against various different
> > broker instances, and I'm finding that, although they're the same
> > version, there are apparently circumstances that exist which make the
> > same call return different collections of attributes across different
> > servers.
> 
> Hi Brian. You're right, this isn't very well documented. I'll try to 
> give an overview here.

This would likely be a lot to document, but perhaps a start would be to document just the base attributes that should be in every single request for a given resource, and then build the docs up from there. So, what should be in an /api/queues response if: 

You're not an admin and:
a) there are no queues
b) there are queues, but no events
c) there are queues and events

You *are* an admin and:
a) there are no queues
b) there are queues, but no events
c) there are queues and events

That'd be a good start, and you can build from there to include attributes with object values that also differ and all the corner case-ish things. 

If there were some kind of collaborative doc project with a moderator or a passthrough for commits, I'd love to know about that, btw.
Let me know!

brian


> 
> There are two reasons why different attributes appear: relevance and 
> permissions.
> 
> The first derives from the fact that internally the mgmt plugin works by 
> receiving statistics events from the various entities (connections, 
> channels, queues) inside the broker. If a certain entity has never done 
> something it'll never emit an event related to that - for example if the 
> queue has only just been created and never received or delivered any 
> messages, it won't have a message_stats attribute. This could also 
> happen if fine-grained stats are disabled - the broker simply isn't 
> emitting the events in this case. Therefore for stats-related 
> attributes, you should always bear in mind that any given metric might 
> be unknown.
> 
> However, that's not what you are seeing. The presence or absence of 
> listeners / nodes etc comes down to the principle that non-administrator 
> users are not meant to be able to see any of the structure of the broker 
> - so they can't learn about which nodes exist other than the one they 
> connect to. They also don't see message rates for vhosts they can't 
> access, even when looking at "global" rates, while administrators do.
> 
> tl;dr: it depends whether you connect as an administrator or not.
> 
> Of course, for monitoring, lots of people want to be able to have a 
> monitoring user which does not have administrator rights but can still 
> see everything. This will hopefully bubble towards the top of the to-do 
> list soon.
> 
> Cheers, Simon
> 
> -- 
> Simon MacMullen
> Staff Engineer, RabbitMQ
> SpringSource, a division of VMware
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com (mailto:rabbitmq-discuss at lists.rabbitmq.com)
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110603/08ca9863/attachment.htm>