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.

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

I've personally built HTTP APIs and eventually rewrote them using AMQP since HTTP couldn't give me guaranteed message delivery (some messages would drop and you wouldn't know about it), couldn't give me overload protection unless I add some specialist layers on top of HTTP (whereas AMQP I could add timeouts on the queues, limit the message rate, move messages I can't immediately process to other queeus so I could notify the publisher that they weren't processed),

I had to build service discovery features with HTTP whereas with AMQP you don't care where the service is sitting, as long as it can see the queue system, with HTTP I had to write code if I want to reroute messages in any way, with AMQP I just add another queue to the exchange and I have plenty of options to reroute messages with many filter options.

With RabbitMQ you get federation and shovel plugins to shovel messages between different instances of RabbitMQ, so if your backend-services goes down for any reason, simply shovel the messages to another instance of RabbitMQ somewhere else so that another backend can process those messages.

Load balancing with RabbitMQ is a breeze, simply add a load balancer in front of different RabbitMQ instances, setup those instances in a cluster formation and startup more services to process messages, with HTTP you need to load balance each individual service.

With RabbitMQ, if I restart a backend while processing a message and it's not done yet, it will requeue automatically and the other backend service will pick it up and process it.

With Java and Spring, I can route all my logging of all applications via RabbitMQ, so I can have all the logging in one place or even write it to a NoSQL database if I wanted to.

With PostgreSQL I can add RabbitMQ on top of the DB as a DB-load-balancer, so writing will do a fan-out to all databases connected, whereas reading will only read from one DB at a time, so using RabbitMQ as read-load-balancer for PostgreSQL just works brilliantly. I can even use it to keep two databases in sync if they are running on different continents, RabbitMQ works well accross continents and adding TLS to RabbitMQ means all that DB-traffic is encrypted.

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!