Why is HTTP not a messaging protocol? (according to RabbitMQ)

Question

In this RabbitMQ documentation, MQTT, AMQP and STOMP are referred to as supported message protocols. If you consider the differences between MQTT, AMQP and STOMP, this is completely understandable to me. However, at the end of this article it becomes confusing. That's about HTTP. This paragraph states that "HTTP is not a course not a messaging protocol". I had thought that HTTP would also be directly supported by RabbitMQ in one way or another, but is only supported for 'low volume messaging purposes' ( diagnostics for example) and for direct use in HTML. If half the world uses HTTP web api services, why HTTP could not be shared among the messaging protocols. Why is HTTP not a messaging protocol and what is the definition RabbitMQ uses of a messaging protocol?

Answer 1

HTTP falls squarely into the synchronous request-response protocols category. This is the very opposite of asynchronous message passing protocols typical of Message-Oriented Middleware.

The 'half of the world' that uses HTTP for web api services does not use it as a loose coupled messaging based web API service, but as a tightly coupled request-response based API.

Messaging protocols come with certain characteristics (at-least-once, exactly-once, at-most-once, exactly-once-in-order etc) which are provided by the protocol definition and implementation. Attempting to do messaging over HTTP quickly devolves into replicating these requirements (retries, sequence numbers, duplicate handling etc) at a layer above HTTP and deprecating HTTP to a transport layer which offers little value from a messaging point of view.