为什么HTTP + Web套接字不适合作为消息传递协议？

Question

I've read that HTTP is not suitable as a messaging protocol in several places such as here in reference to RabbitMQ.

I assume that there's a technical reason for this and that it's not a mere opinion. I've looked through the AMQP spec for example and can't see any reason why HTTP + Web Sockets can't work. In fact, something seems to be in the works for AMQP over Web Sockets. Furthermore, I've looked at the STOMP protocol which does use HTTP + Web Sockets and can't see any significant limitations (other than a small performance hit).

What technical characteristic does HTTP + Web Sockets lack that makes it unsuitable as a messaging protocol?

UPDATE: This is what I was looking for: Crossbar.IO - a WAMP message broker. I needed a message broker that I can easily connect to from a browser and have not been satisfied with RabbitMQ (over STOMP) or HiveMQ (MQTT).

Answer 1

HTTP is request/response based, what makes it difficult to work in a publisher/subscriber fashion. Basically, you can either poll the source of messages for new ones, or create another local endpoint where the other end push messages to you.

WebSocket is different. Despite of starting as a HTTP request, it switches straightaway to a persistent, full-duplex connection, where both end can push data. Basically, in this case HTTP is only used as protocol to negotiate the connection, once negotiated WebSocket uses its own protocol to transfer data.

UPDATE: We are clear that HTTP is not a messaging protocol, since it is request/response. WebSockets, although it allows pushing data from both ends, it is not a messaging protocol neither. It defines a way of framing data, but there are not defined semantic or grammar to subscribe to topics or any operation about messaging. For example WAMP is an actual messaging protocol for websockets.