Request-Response über WebSockets
Lernen Sie Techniken kennen, um traditionelle Request-Response-Semantik mithilfe von WebSocket-Nachrichten-IDs und Bestätigungen zu simulieren.
Request-Response über WebSockets ist eine kostenlose WebSockets & Realtime Systems Programming-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des WebSockets & Realtime Systems Programming-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der WebSockets & Realtime Systems Programming-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Beyond Fire-and-Forget
WebSockets are fantastic for real-time, continuous streams of data. Think chat messages, live updates, or game states!
But what if you need to perform a traditional request-response interaction, like fetching specific data from a server and expecting a single, matching reply?
The Asynchronous Nature
Unlike HTTP, where each request gets an immediate, direct response, WebSockets operate on an asynchronous, message-based model.
When you send a message over a WebSocket, you don't automatically know which incoming message is its specific reply. It's like sending a letter and waiting for a specific reply letter in a pile of mail!
Unique Request Identifiers
To solve this, we introduce a crucial concept: Message IDs. Every time a client sends a request, it attaches a unique identifier.
The server then processes the request and includes that same identifier in its response. This allows the client to match the response to its original request.
Client-Side Request Tracking
On the client, we need a way to track which requests are pending and what to do when their responses arrive. A common pattern is to use a Map or object to store a Promise for each pending request.
Try running this basic setup in your browser's console:
const ws = new WebSocket("ws://localhost:8080");
const pendingRequests = new Map();
ws.onopen = () => console.log("WebSocket Connected!");
ws.onclose = () => console.log("WebSocket Disconnected.");
ws.onerror = (error) => console.error("WebSocket Error:", error);
// This will be updated later to handle responsesServer Responds with ID
The server's role is simple: when it receives a message with an id, it should process it and send back a response that includes the same id.
Here's a simplified Node.js server snippet:
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', ws => {
ws.on('message', message => {
const request = JSON.parse(message);
console.log('Received:', request);
// Assume processing takes time...
setTimeout(() => {
const response = {
id: request.id, // Echo the original ID!
type: 'response',
payload: `Hello from server, for request ${request.id}`
};
ws.send(JSON.stringify(response));
}, 1000);
});
});
console.log('Server started on ws://localhost:8080');The Full Cycle in Action
Let's trace a request-response cycle:
- Client generates unique
id(e.g., 1). - Client stores a
Promiseforid: 1inpendingRequests. - Client sends
{id: 1, type: 'fetchUser', userId: 123}. - Server receives, processes, and prepares response.
- Server sends
{id: 1, type: 'userFetched', data: {...}}. - Client receives message, looks up
id: 1inpendingRequests, and resolves itsPromise.
A `sendRequest` Function
To make sending requests easier, we can wrap the logic in a helper function. This function will generate an ID, store a promise, send the message, and return the promise.
Add this to your client-side code:
let nextRequestId = 0;
function sendRequest(type, payload) {
const requestId = nextRequestId++;
const message = { id: requestId, type, payload };
return new Promise((resolve, reject) => {
pendingRequests.set(requestId, { resolve, reject, timeoutId: null });
ws.send(JSON.stringify(message));
console.log("Sent request:", message);
// We'll add timeout logic soon!
});
}
// Example usage (after ws is open):
// sendRequest('getUser', { id: 1 }).then(data => console.log(data));Processing Server Responses
Now, let's update our client's ws.onmessage handler to correctly process incoming server responses and resolve (or reject) the associated promises.
This is where the pendingRequests map truly shines!
ws.onmessage = (event) => {
const message = JSON.parse(event.data);
console.log("Received:", message);
const { id, error, payload } = message;
if (pendingRequests.has(id)) {
const { resolve, reject, timeoutId } = pendingRequests.get(id);
clearTimeout(timeoutId); // Important: clear the timeout!
pendingRequests.delete(id); // Remove from tracking
if (error) {
reject(new Error(error));
} else {
resolve(payload); // Resolve with the response payload
}
} else {
console.warn("Unmatched message ID or broadcast received:", message);
// Handle messages that are not direct responses to a request (e.g., broadcasts)
}
};Timeouts and Error Handling
What if the server never responds? Or the connection drops?
It's crucial to implement timeouts for pending requests. If a response isn't received within a set duration, the client should automatically reject the promise with a timeout error.
This prevents requests from hanging indefinitely and consuming memory.
Check Your Understanding
Which of the following are essential components for implementing a robust request-response pattern over WebSockets?
Recap: Request-Response
You've learned how to simulate a traditional request-response model using WebSockets!
- Unique Message IDs: Attach an ID to each request.
- Client-Side Tracking: Use a
Mapto storePromises for pending requests. - Server Echo: Server includes the request ID in its response.
- Timeouts: Implement timeouts to handle unreceived responses gracefully.
This pattern makes WebSockets incredibly versatile for both streaming and discrete data exchanges!
Lerne WebSockets & Realtime Systems Programming mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 12
- Lektionen
- 47
Häufig gestellte Fragen
Ist die Lektion „Request-Response über WebSockets“ kostenlos?
Ja — der vollständige Text von „Request-Response über WebSockets“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des WebSockets & Realtime Systems Programming-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der WebSockets & Realtime Systems Programming-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Request-Response über WebSockets“?
Lernen Sie Techniken kennen, um traditionelle Request-Response-Semantik mithilfe von WebSocket-Nachrichten-IDs und Bestätigungen zu simulieren. Du übst WebSockets & Realtime Systems Programming mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um WebSockets & Realtime Systems Programming zu starten?
Keine Vorkenntnisse erforderlich. WebSockets & Realtime Systems Programming auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Request-Response über WebSockets“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser WebSockets & Realtime Systems Programming-Lektion Code schreiben und ausführen?
Ja. Jede WebSockets & Realtime Systems Programming-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Publish/Subscribe-Messaging implementieren
- Request-Response über WebSockets
- Bidirektionales Streaming und Flusskontrolle
- Backpressure und Nachrichten-Batching