At DEVOXX last year I was cringing when I heard a talk where they went into depth about how to make HTTP work as a SOA layer and kept telling myself ... but AMQP already solved all those issue, why re-invent that with HTTP with layers upon layers of complexity?
HTTP you've probably heard about, if you've never about AMQP, here's a short snippet from Wikipedia:
AMQP is a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns. It provides flow controlled, message-oriented communication with message-delivery guarantees such as at-most-once (where each message is delivered once or never), at-least-once (where each message is certain to be delivered, but may do so multiple times) and exactly-once (where the message will always certainly arrive and do so only once), and authentication and/or encryption based on SASL and/or TLS. It assumes an underlying reliable transport layer protocol such as Transmission Control Protocol (TCP).
The AMQP specification is defined in several layers: (i) a type system, (ii) a symmetric, asynchronous protocol for the transfer of messages from one process to another, (iii) a standard, extensible message format and (iv) a set of standardised but extensible 'messaging capabilities.
And some more reading from the AMQP specifications themselves:
If you've used any of the two, what was your experience?
Yes! AMQP is great for interconnecting internal components and it's damn fast! For external APIs (JSON / SOAP), i simply add an HTTP endpoint on the frontend that's connected to the rest of the system via AMQP. This kind of setup is very easy to scale!
Remco Boerma
CTO@NPO, python dev, dba
AMQP is a great messaging protocol. Messaging is an important part of what the web is about. HTTP is more widely used however. And there are few more messaging protocols each with their own benefits.
I can imagine exposing the system through AMQP partely provided using a HTTP/rEST, HTTP/jsonrpc2, HTTP/soap gateway. I can also imagine HTTP being used for some parts of the system (think microservices architecture where subsystems are partly exposed using HTTP) while all those subsystems are interconnected using AMQP, and to which you maybe also offer access. Depending on the messaging needs.