RabbitMQ is a message broker that allows clients to connect over different open and standardized protocols such as AMQP, HTTP, STOMP, MQTT, MQTT over WebSockets and STOMP over WebSockets.
HTTP stands for Hypertext Transfer Protocol, and it is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP is not a messaging protocol. However, RabbitMQ can transmit messages over HTTP.
The rabbitmq-management plugin provides an HTTP-based API for the management and monitoring of your RabbitMQ server. It enables by default on all CloudAMQP instances and assigned port 443.
The full HTTP API reference can be found in the official RabbitMQ Management HTTP API documentation, or in the LavinMQ management HTTP API documentation.
The HTTP API uses
basic authentication
(the
Authorization
header). In the examples on this page, this is handled by the
curl
--user
flag.
Example of how to publish a message to the default exchange with the routing key my_key:
curl --user username:password \
--json '{"properties":{},"routing_key":"my_key","payload":"my body","payload_encoding":"string"}' \
https://hostname/api/exchanges/your_vhost/amq.default/publish
The response will be in JSON, telling you if the message was routed or not.
Example of how to get one message from the Queue your_queue . (This is not an HTTP GET as it will alter the Queue’s state.)
curl --user username:password \
--json '{"count":1,"requeue":true,"encoding":"auto"}' \
https://hostname/api/queues/your_vhost/your_queue/get
The response will be in JSON, with the message payload and various properties.
curl --user username:password https://hostname/api/queues/your_vhost/your_queue
The response will be in JSON, with various information about the queue.
When arrive faster to the queue than they are processed - and when the queue starts growing in length, it is good to spin up more workers. The idea is to poll the HTTP API queue length and spin up or take down workers depending on the length.