I understand that HTTP is text-based and AMQP is binary-based, but why can't AMQP be implemented over HTTP (meaning every binary message was sent as an HTTP payload)? I assume it's because it would be slow to have to constantly serialize/deserialize every back and forth?
How does the STOMP protocol address this? I get that it moves the binary-to-text conversion to the server, but at the expense of the "messages" being larger so is it really that much faster than a JS client that can serialize/deserialize AMQP?
While this question is tends to be primarily opinion-based, have a look at section 1.2.4 The Advanced Message Queuing Protocol (AMQP) in AMQP Protocol Specification:
The design of AMQ model was driven by these requirements:
- To guarantee interoperability between conforming implementations.
- To provide explicit control over the quality of service.
- To be consistent and explicit in naming.
- To allow complete configuration of server wiring via the protocol.
- To use a command notation that maps easily into application-level API's.
- To be clear, so each operation does exactly one thing.
The design of AMQP transport layer was driven by these main requirements, in no particular order:
- To be compact, using a binary encoding that packs and unpacks rapidly.
- To handle messages of any size without significant limit.
- To carry multiple channels across a single connection.
- To be long-lived, with no significant in-built limitations.
- To allow asynchronous command pipe-lining.
- To be easily extended to handle new and changed needs.
- To be forward compatible with future versions.
- To be repairable, using a strong assertion model.
- To be neutral with respect to programming languages.
- To fit a code generation process.
For better understanding (e.g. why one decisions was preferred over another) reading through whole specification is highly recommended.