What is the difference between WebSocket and STOMP protocols?

What are the major differences between WebSocket and STOMP protocols?

This question is similar to asking the difference between TCP and HTTP. I shall still try to address your question, its natural to get confused between these two terms if you are beginning.

Short Answer

STOMP is derived on top of WebSockets. STOMP just mentions a few specific ways on how the message frames are exchanged between the client and the server using WebSockets.

---

Long Answer

WebSockets

It is a specification to allow asynchronous bidirectional communication between a client and a server. While similar to TCP sockets, it is a protocol that operates as an upgraded HTTP connection, exchanging variable-length frames between the two parties, instead of a stream.

STOMP

It defines a protocol for clients and servers to communicate with messaging semantics. It does not define any implementation details, but rather addresses an easy-to-implement wire protocol for messaging integrations. It provides higher semantics on top of the WebSockets protocol and defines a handful of frame types that are mapped onto WebSockets frames. Some of these types are...

• connect
• subscribe
• unsubscribe
• send (messages sent to the server)
• message (for messages send from the server) BEGIN, COMMIT, ROLLBACK (transaction management)

WebSocket does imply a messaging architecture but does not mandate the use of any specific messaging protocol. It is a very thin layer over TCP that transforms a stream of bytes into a stream of messages (either text or binary) and not much more. It is up to applications to interpret the meaning of a message.

Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is simply not enough information in an incoming message for a framework or container to know how to route it or process it. Therefore WebSocket is arguably too low level for anything but a very trivial application. It can be done, but it will likely lead to creating a framework on top. This is comparable to how most web applications today are written using a web framework rather than the Servlet API alone.

For this reason the WebSocket RFC defines the use of sub-protocols. During the handshake, the client and server can use the header Sec-WebSocket-Protocol to agree on a sub-protocol, i.e. a higher, application-level protocol to use. The use of a sub-protocol is not required, but even if not used, applications will still need to choose a message format that both the client and server can understand. That format can be custom, framework-specific, or a standard messaging protocol.

STOMP — a simple, messaging protocol originally created for use in scripting languages with frames inspired by HTTP. STOMP is widely supported and well suited for use over WebSocket and over the web.

The WebSocket API enables web applications to handle bidirectional communications whereas STOMP is a simple text-orientated messaging protocol.

The STOMP protocol is commonly used inside a web socket when a web app needs to support bidirectional communication with a web server.

A good tutorial is STOMP Over WebSocket by Jeff Mesnill (2012)

STOMP can also be used without a websocket, e.g. over a Telnet connection or a message broking service.

And Raw WebSockets can be used without STOMP - Eg. Spring Boot + WebSocket example without STOMP and SockJs.

Note: Others have well explained what are both WebSocket and STOMP, so I'll try to add the missing bits.

The WebSocket protocol defines two types of messages (text and binary), but their content is undefined.

STOMP protocol defines a mechanism for client and server to negotiate a sub-protocol (that is, a higher-level messaging protocol) to use on top of WebSocket to define following things:

• what kind of messages each can send,
• what the format is,
• the content of each message, and so on.

The use of a sub-protocol is optional but, either way, the client and the server need to agree on some protocol that defines message content.

Reference