Request-Response

At the heart of the client-server model lies a deceptively simple interaction: the client asks, the server answers. This request-response pattern is the fundamental communication paradigm that governs how clients and servers exchange information. Every HTTP call, every database query, every API invocation follows this pattern—a client formulates a request expressing what it wants, transmits it to a server, and waits for a response that fulfills (or rejects) that request.

Understanding request-response deeply means understanding how networked applications communicate. This pattern isn't merely a convention; it's the logical structure that enables loosely-coupled, scalable distributed systems.

The request-response model is a communication pattern where:

1. The client initiates by sending a request message to the server
2. The server processes the request, performing whatever operations are required
3. The server responds by sending a response message back to the client
4. The client processes the response, acting on the information received

This is a pull-based model—the client pulls data from the server when it wants it. The server doesn't push data unprompted; it only responds when asked.

Key Characteristics:

Why This Pattern Dominates:

The request-response pattern is nearly universal in networked computing for good reasons:

1. Simplicity — Easy to understand, implement, and debug. The cause-effect relationship is clear.

2. Reliability — The client knows whether its request succeeded based on the response (or timeout).

3. Scalability — Stateless request-response enables load balancing across multiple servers.

4. Interoperability — Standard request/response protocols (HTTP, SQL, etc.) enable heterogeneous systems to communicate.

A well-formed request must communicate several pieces of information to the server. While specific protocols vary, most requests share common structural components.

HTTP Request Example:

Breakdown of the HTTP Request:

Request Semantics by Method:

HTTP methods define the intent of the request:

• Idempotent: Multiple identical requests have the same effect as one request
• Safe: Request doesn't modify server state (read-only)

*PATCH is contentiously idempotent depending on patch semantics

Responses communicate the result of the server's processing—whether the request succeeded, failed, or requires further action. Like requests, responses have a defined structure.

HTTP Response Example:

HTTP Status Code Categories:

Critical Status Codes to Know:

In synchronous request-response, the client sends a request and blocks until it receives the response. This is the most intuitive and common pattern—the client waits for the answer before proceeding.

Characteristics of Synchronous Pattern:

When Synchronous Works Well:

• Operations that complete quickly (< 100ms)
• Simple command-line tools and scripts
• Operations where the caller truly has nothing else to do
• Sequential operations where each step depends on the previous

When Synchronous Becomes Problematic:

• High-latency operations (network calls across continents, complex computations)
• Need to make multiple independent requests (sequential is slow)
• Interactive applications where blocking freezes the UI
• Servers handling many clients (thread-per-request doesn't scale)

In asynchronous request-response, the client sends a request and then continues executing without waiting for the response. The response is handled when it arrives, typically via callbacks, promises, or async/await constructs.

Asynchronous Programming Models:

1. Callbacks

The traditional approach—pass a function to be called when the response arrives:

fetchUser(userId, (error, user) => {
    if (error) { handleError(error); return; }
    fetchOrders(user.id, (error, orders) => {
        // Nested callback - "callback hell"
    });
});

Problem: Deeply nested callbacks become unreadable ("callback hell").

2. Promises

Represent a future value that may resolve or reject:

fetchUser(userId)
    .then(user => fetchOrders(user.id))
    .then(orders => displayOrders(orders))
    .catch(error => handleError(error));

Better: Chainable, single error handler, but still somewhat awkward.

3. Async/Await

Syntactic sugar making async code look synchronous:

async function loadData(userId) {
    try {
        const user = await fetchUser(userId);
        const orders = await fetchOrders(user.id);
        displayOrders(orders);
    } catch (error) {
        handleError(error);
    }
}

Best: Reads like synchronous code but executes asynchronously.

The request-response pattern is implemented differently across various protocols, each optimizing for its specific use case. Understanding these variations reveals the universality and flexibility of the pattern.

HTTP/2 Multiplexing: A Key Evolution

HTTP/1.1 has a fundamental limitation: only one request-response exchange can be in flight per connection at a time (head-of-line blocking). To make multiple simultaneous requests, clients open multiple connections—wasteful and limited.

HTTP/2 introduced multiplexing: many requests and responses can be interleaved on a single connection, each identified by a stream ID:

Connection:
  Stream 1: Request A headers
  Stream 3: Request B headers
  Stream 1: Request A data
  Stream 3: Request B data
  Stream 1: Response A headers + data
  Stream 3: Response B headers
  Stream 3: Response B data

This transforms the request-response model from strictly sequential to highly concurrent over a single TCP connection, dramatically improving efficiency for web pages with many resources.

Robust request-response handling must account for the many ways interactions can fail. Errors occur at every layer—network, transport, protocol, and application—and must be handled appropriately.

Idempotency and Safe Retries:

The key question when an error occurs: is it safe to retry?

• Idempotent operations (GET, PUT, DELETE) can be safely retried—repeating them has the same effect as doing them once
• Non-idempotent operations (POST, some PATCH) may not be safely retriable—a retry might create duplicate data

Example Problem:

Client: POST /orders (create order)
Server: Processes request, creates order, starts sending response
Network: Connection drops before response reaches client
Client: Sees timeout error - did the order get created?
        If retry: might create duplicate order
        If don't retry: might have lost the order

Solutions:

1. Idempotency Keys: Client sends unique key with request; server deduplicates:

   POST /orders
   Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
   

2. Request IDs for Correlation: Include ID in request, check if already processed before retry

3. Two-Phase Operations: First request reserves/stages; second request confirms