Send bidirectional messages between services with WebSocket

The WebSocket protocol enables two-way communication between client and server endpoints by using a Transmission Control Protocol (TCP) connection. Both client and server can send and receive messages simultaneously, without having to wait for a response. Furthermore, the connection remains open until it is explicitly closed, so messaging can occur in real time without interruptions.

WebSocket is beneficial for applications that need to frequently send and receive messages with minimal latency, such as applications for chat, gaming, or virtual collaboration. For example, an online multiplayer racing game might use the WebSocket protocol to receive each player’s position while it sends the location of the other players back to each browser client.

To initiate a WebSocket connection, a client sends a WebSocket handshake request to a server over HTTP. This request includes a request to upgrade from the HTTP protocol to the WebSocket protocol, where the new communication occurs. After the connection is established, the server can send and receive messages among one or more clients simultaneously until the connection is closed.

To use the WebSocket protocol with your Open Liberty applications, enable the Jakarta WebSocket feature in your server.xml file. This feature enables support for applications that use the Jakarta WebSocket API. You can learn how to use Jakarta WebSocket with Open Liberty in the Bidirectional communication between services using Jakarta WebSocket guide.

The WebSocket protocol can be an alternative to REST for some application needs, though the comparison is not one-to-one. Depending on the context, REST communication is still a preferred choice for many web applications, while others might benefit from Server-Sent Events (SSE), another alternative to WebSocket.

Any comparison between WebSocket and REST is essentially a comparison between WebSocket and HTTP, the protocol that REST relies on. Although WebSocket uses HTTP to establish a connection, any ensuing messages are sent over a persistent TCP connection. The same connection can remain open for multiple messages. By contrast, REST requests establish a new TCP connection for each message, which can lead to higher latency per message than with WebSocket. Every REST request also includes its own HTTP headers, which in some instances might be longer than the actual message data.

Furthermore, with WebSocket, a client and server can send and receive messages simultaneously, without having to wait for a response. This type of communication is not feasible with REST, where a server must wait for a request before it sends data to a client. Another advantage of WebSocket is the ability for a server to send messages to multiple clients at the same time.

Although REST is a widely adopted design pattern, WebSocket might be preferred for scenarios where a server sends and receives multiple real-time, low-latency messages among one or more clients. For example, chat applications or multiplayer games might benefit from using WebSocket connections instead of REST over HTTP.

Server-Sent Events is an API that allows clients to subscribe to a stream of events that is pushed from a server. First, the client makes a connection with the server over HTTP. The server continuously pushes events to the client while the connection persists. SSE differs from traditional HTTP requests, which use one request for one response. SSE also differs from WebSocket in that SSE is unidirectional from the server to the client, while WebSocket is bidirectional. However, WebSocket can be more complex to set up than SSE, which uses HTTP and doesn’t require a separate protocol.

SSE is useful for applications that need to send multiple low-latency messages from server to client but don’t require bidirectional communication. For example, applications that use push notifications or provide realtime sports updates might benefit from using SSE instead of WebSocket. For more information about SSE with Open Liberty, see the Streaming updates to a client using Server-Sent Events guide.