This article focuses on three mainstream communication patterns—HTTP, SSE, and WebSocket. It explains their fundamental differences in request-response workflows, one-way streaming delivery, and bidirectional real-time messaging, helping developers choose the right approach for CRUD APIs, AI streaming output, chat rooms, live comments, and similar scenarios. Keywords: HTTP, SSE, WebSocket.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Core topic | Communication architecture choices for HTTP / SSE / WebSocket |
| Primary languages | Java, JavaScript |
| Related protocols | HTTP/1.1, text/event-stream, WebSocket, STOMP |
| Typical frameworks | Spring Web, Spring WebSocket |
| Core dependencies | SseEmitter, SockJS, STOMP |
| Original platform info | Originally published on CSDN, approximately 518 views, 16 likes, 8 bookmarks |
These three communication patterns solve problems at different layers
Most backend systems use HTTP by default: a request arrives, the server processes it, returns a result, and the interaction ends immediately. This model covers the vast majority of CRUD operations, REST APIs, and file upload/download scenarios.
But when the business goal shifts from “get a result” to “keep receiving results” or “both sides need to talk at any time,” the limits of HTTP become obvious. At that point, you either introduce SSE for server-side streaming pushes or use WebSocket to establish a true full-duplex channel.
AI Visual Insight: This diagram uses a conversation metaphor to illustrate the behavioral differences among the three models: HTTP ends after a single question-and-answer exchange, SSE keeps the server talking, and WebSocket enables continuous two-way conversation. It helps developers build a first-principles understanding of protocol selection.
You can remember their boundaries with one sentence each
- HTTP: one request, one response
- SSE: the server keeps talking, the client keeps listening
- WebSocket: both sides can talk at any time
HTTP -> Request/response, naturally suited for discrete operations
SSE -> One-way event stream built on top of HTTP
WebSocket -> Bidirectional persistent connection after protocol upgradeThis summary snippet establishes a mental model of the three protocols with the smallest possible amount of information.
HTTP remains the default and safest foundation
HTTP runs on top of TCP, and its core model is request-response. The client initiates a request, and the server returns a result. Even with Keep-Alive enabled, the connection may be reused, but the semantics are still client-driven.
Its strengths are clear: a mature ecosystem, cache friendliness, strong compatibility with proxies and gateways, and simple debugging. Its limitations are equally clear: the server cannot naturally push continuous data, and HTTP is not well suited for high-frequency real-time interaction.
AI Visual Insight: The diagram shows HTTP as a linear path: the browser sends a request, the server processes it, and then returns a response. The connection lifecycle is short and triggered by the client, highlighting HTTP’s synchronous, discrete, and one-shot communication characteristics.
A minimal Spring HTTP endpoint example
@RestController
public class UserController {
@GetMapping("/api/user")
public User getUser() {
// Return a fixed user object to simulate a standard query endpoint
return new User("张三", 18);
}
}This code shows the most typical HTTP API pattern: the client sends one request, and the server returns one response.
HTTP is a clear fit for these scenarios
- Standard admin systems
- CRUD APIs for products, orders, users, and similar entities
- File uploads and downloads
- Page refresh flows with low real-time requirements
SSE is the most natural way to implement AI streaming output
SSE is part of the HTML5 standard. In essence, it still runs over HTTP, but it uses the text/event-stream response header, keeps the connection open, and allows the server to continuously write event data.
That makes SSE ideal for business scenarios where results arrive progressively, such as LLM token streaming, task progress updates, stock quotes, and log delivery. Compared with WebSocket, SSE is lighter to implement and friendlier to operate.
AI Visual Insight: The diagram emphasizes that the client opens the connection only once, while the server keeps pushing event messages over the same path. It reflects how SSE uses a long-lived HTTP connection to deliver low-latency one-way streaming data.
Using SseEmitter in Spring for server push
@RestController
public class SseController {
@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter stream() {
SseEmitter emitter = new SseEmitter();
// Send messages continuously on an async thread to avoid blocking the request thread
Executors.newSingleThreadExecutor().execute(() -> {
try {
for (int i = 0; i < 10; i++) {
emitter.send("消息 " + i); // Continuously push event data
Thread.sleep(1000); // Simulate progressively generated content
}
emitter.complete(); // Close the stream explicitly when pushing is done
} catch (Exception e) {
emitter.completeWithError(e); // Notify the frontend when an error occurs
}
});
return emitter;
}
}This code creates an SSE endpoint that can continuously output messages.
const eventSource = new EventSource('/stream');
eventSource.onmessage = (event) => {
// Continuously receive text content pushed by the server
console.log('Received:', event.data);
};This frontend code subscribes to an SSE stream and consumes server messages in real time.
The value and limitations of SSE are both straightforward
Its advantages are lightweight implementation, HTTP-based transport, native browser support, and friendly automatic reconnection behavior. Its disadvantages are also clear: it only supports one-way transmission from server to client, and it mainly targets text events rather than complex bidirectional interaction.
If your goal is to build RAG conversations, an AI typewriter effect, exam countdown timers, or system announcement delivery, SSE is often more disciplined—and more correct—than WebSocket.
WebSocket provides true bidirectional real-time communication
WebSocket starts with an HTTP handshake. After the server returns 101 Switching Protocols, the connection upgrades into an independent protocol, and both sides can actively send messages.
That means WebSocket is not simply “HTTP with stronger server push.” It is a long-lived session channel designed for interaction-heavy systems, and it fits chat rooms, live comments, collaborative editing, online games, and real-time dashboards.
AI Visual Insight: The diagram highlights two key stages—handshake upgrade and persistent connection. The client and server first negotiate over HTTP, then switch to a bidirectional messaging channel, reflecting WebSocket’s low-latency, duplex, and session-oriented nature.
Spring WebSocket configuration example
@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/ws").withSockJS(); // Register the connection endpoint and enable fallback support
}
@Override
public void configureMessageBroker(MessageBrokerRegistry registry) {
registry.enableSimpleBroker("/topic"); // Enable a simple message broker
registry.setApplicationDestinationPrefixes("/app"); // Define the application message prefix convention
}
}This configuration exposes the WebSocket endpoint and defines STOMP message routing.
const socket = new SockJS('/ws');
const stompClient = Stomp.over(socket);
stompClient.connect({}, () => {
stompClient.subscribe('/topic/room/123', (msg) => {
// Receive broadcast messages for the room in real time
console.log('Bullet comment:', msg.body);
});
// Actively send a message from the client to the server
stompClient.send('/app/chat', {}, JSON.stringify({ content: '666' }));
});This frontend example demonstrates WebSocket’s bidirectional capability for both subscribing to broadcasts and actively sending messages.
The differences in protocol selection can be compressed into one decision table
AI Visual Insight: This graphic compares communication direction, protocol foundation, complexity, real-time characteristics, and suitable business cases in a table format. It works well for quickly explaining technical choices in architecture reviews or interviews.
You can follow this rule set for protocol selection
| Requirement | Recommended option | Reason |
|---|---|---|
| Standard API calls | HTTP | Simple, stable, and low operational overhead |
| AI streaming responses | SSE | Best fit for one-way streaming output |
| Logs, notifications, countdown timers | SSE | Only server-initiated push is needed |
| Chat rooms, live comments, collaborative editing | WebSocket | Requires bidirectional real-time communication |
| High-frequency interactive games | WebSocket | Lower latency and stronger interaction model |
AI Visual Insight: This decision diagram uses a branching flow to turn “Do you need real time?” and “Do you need bidirectional communication?” into an explicit selection path. It works well as a standardized decision template in team design reviews.
In engineering practice, choose the more disciplined option first
The first principle is not “which one is more advanced,” but “which one fits the requirement exactly.” If HTTP is enough, do not introduce long-lived connections. If you only need server push, do not move to WebSocket prematurely.
The second principle is infrastructure awareness. Both SSE and WebSocket consume long-lived connections, so you need to evaluate browser connection limits, gateway timeouts, thread models, and connection management strategies.
How to choose for an online examination system
If the requirement is to display the remaining time in real time and receive teacher announcements instantly, while students do not need to continuously send messages, choose SSE first. This is a classic one-way broadcast scenario from server to client.
Compared with WebSocket, SSE runs on HTTP, passes through existing proxies and gateways more easily, and keeps implementation simpler for examination systems with thousands of concurrent users. Answer submission can still use HTTP, forming a combined “HTTP + SSE” architecture.
FAQ
FAQ 1: What is the most important difference between SSE and WebSocket?
Answer: SSE is one-way communication: the server continuously pushes data to the client. WebSocket is full-duplex communication: both the client and server can send messages at any time. If you only need push delivery, choose SSE first. If you need real-time interaction, choose WebSocket.
FAQ 2: Why is SSE usually the first choice for AI chat streaming output?
Answer: Because AI-generated content is typically produced continuously by the server and rendered continuously by the client, which naturally matches the one-way streaming model. SSE is HTTP-based, easy to integrate, easy to debug, and more compatible with proxies.
FAQ 3: Can HTTP, SSE, and WebSocket coexist in the same system?
Answer: Yes—and that is often the best practice. Use HTTP for standard queries and submissions, SSE for streaming status updates or notifications, and WebSocket for highly interactive modules such as chat rooms or live comments. This balance gives you the right trade-off across complexity, cost, and user experience.
Core summary: This article systematically breaks down the communication models, protocol differences, strengths, weaknesses, and typical use cases of HTTP, SSE, and WebSocket. It also uses Spring and Java examples to show how to make the right choice for standard APIs, AI streaming output, chat rooms, and live comment systems.