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:

amqp.org/product/solve

amqp.org/product/overview

If you've used any of the two, what was your experience?

Write your answer…

If you're building for large intranets and have close communication with developing parties on both sides, I'm sure AMQP is a great protocol/standard to use. If you're building for the web/cloud, it seems to me you're better of with the standard that is already in use, adopted and useable without extra effort on standard hardware: HTTP/REST

1 Beer1
Show all replies

For anything external-facing that people integrate into, sure, HTTP makes sense, but that doesn't stop you from using AMQP (or both) as I've seen some companies does.

If you replace the HTTP endpoint with an AMQP endpoint, you get everything you'd get with HTTP minus the unreliability of HTTP. The message you POSTed to your HTTP endpoint, you now simply publish to the AMQP endpoint.

With HTTP there IS extra effort you need to do, service discovery, overload protection, retry-if-fail in certain cases, load-balancing, etc whereas AMQP gives you all of the out of the box with much better throughput.

Reply to this…

Hashnode is building a friendly and inclusive dev community. Come jump on the bandwagon!

  • 💬 A beginner friendly place

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 >500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Register ( 500k+ developers strong 👊)

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.

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!

Reply to this…