REST API support in RabbitMQ

1,209 views
Skip to first unread message

Danesh Daroui

unread,
Jun 7, 2017, 9:02:54 AM6/7/17
to rabbitmq-users
Dear all,

I have a basic question about RabbitMQ message broker. Hope there will be someone to help me to clarify things.

I know that RabbitMQ supports AMQP, so now the question is whether it is possible to implement a REST API server and client between several microservices suign RabbitMW or not? I mean, would it be possible to use RabbitMQ to send and handle GET/POST/DELETE/PUT/... API commands at each microservice running on cloud?

The other question is what library would you recommend to use in order to implement client/server solution using RabbitMQ in C++? Sadly, RabitMQ does not provide any official interface for C++ and all libraries are third parties, but I would appreciate if anyone give me a hint about a proper library that he/she has used and is satisfied with.

Thanks for your help,

Dan

Michael Klishin

unread,
Jun 7, 2017, 9:28:57 AM6/7/17
to rabbitm...@googlegroups.com
GET, POST, PUT and DELETE are HTTP 1.1 operations. You can imitate them
with other protocols by sending HTTP request bodies in message payload but I'm not sure if it's
worth the effort as the upside will primarily be limited to more flexible routing but every other
messaging protocol feature won't be available.

There are 3 C++ libraries listed on http://www.rabbitmq.com/devtools.html,
roughly in the order they appeared/became known in.

https://github.com/alanxz/SimpleAmqpClient is the library I personally see used most often.
https://github.com/akalend seems to support new-ish C++ features.
https://github.com/CopernicaMarketingSoftware/AMQP-CPP is mentioned in the community less often
but according to the README it is used in 3 commercial products, which is always an encouraging sign.

The best part is perhaps that all of them have been updated in the last month, which means they are
not abandoned by their maintainers.


--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
MK

Staff Software Engineer, Pivotal/RabbitMQ

Michael Klishin

unread,
Jun 7, 2017, 9:29:15 AM6/7/17
to rabbitm...@googlegroups.com
The 2nd library link should be https://github.com/akalend/amqpcpp, sorry.

To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

Danesh Daroui

unread,
Jun 7, 2017, 10:08:32 AM6/7/17
to rabbitmq-users
Hi Michael,

Thanks for your answer! I guess embedding HTTP requests in the payload of the message is kind of dirty hack and it is not really recommended since (as you mentioned) it would be hard to keep it synched with every change in the protocol and also parsing the requests correctly can be error prone. I am surprised that HTTP API commands are not supported in such famous message broker like RabbitMQ but maybe it is by purpose that it is initially designed to support AMQP for a certain class of applications.

Regards,

Dan
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Michael Klishin

unread,
Jun 7, 2017, 10:56:30 AM6/7/17
to rabbitm...@googlegroups.com
What specifically do you mean by "HTTP API commands"?

RabbitMQ has an HTTP API for metrics and monitoring. You can even publish and consume via it, although it
is not recommended as it is drastically less efficient than other protocols supported.

Applications that use RabbitMQ use one of the messaging protocols we support, which
means ideas and frameworks built around HTTP are not really applicable.

HTTP 1.1 is not a great choice for messaging if you ask me (HTTP/2 is much more adequate in that area).

Some of your services can use HTTP, others RabbitMQ, some can use both
(e.g. an HTTP API for metrics in monitoring makes perfect sense in a service
that consumes events using AMQP 0-9-1). I would not recommend trying to adapt
existing HTTP-oriented frameworks to AMQP or STOMP or MQTT.

RabbitMQ supports STOMP and MQTT over WebSockets, that can be used to bridge
the gap in some cases.
Reply all
Reply to author
Forward
0 new messages