Client–Server Architecture and the Request–Response Cycle

By the end of this lesson you will be able to

• Explain the client–server model: who starts a conversation, who holds the data, and why it is called centralised.
• Walk through the request–response cycle in five phases, from a click to a rendered page.
• Take a URL apart (scheme, host, port, path, query, fragment) and say who uses each part.
• Read a raw HTTP request and response: request line, status line, headers, blank line, body.
• Choose the right method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) and say which are safe and which are idempotent.
• Interpret status codes from 1xx to 5xx, including the ones interviewers love: 201, 204, 304, 401 vs 403, 409, 429, 502, 503, 504.
• Explain keep-alive, HTTP/1.1 vs HTTP/2 vs HTTP/3, and how a client should handle timeouts and retries without doing anything twice.

#What client–server means

Client–server architecture is the foundation of web networking. It is a centralised model in which the work is split into two roles:

• Client: the side that asks for a service or data. Examples: your web browser, a mobile app, Postman, the curl command.
• Server: the side that holds the data, the logic and the resources in one central place, and answers clients’ requests. Examples: Nginx, Apache, a Node.js/Express app, a Spring Boot server. What a server really is (machine, program, port) is the next lesson; how Nginx, Apache and app servers work inside is in Web Servers and App Servers.

  +-----------------+                          +-----------------+
  |                 | ──── 1. HTTP Request ──► |                 |
  |     Client      |                          |     Server      |
  |  (Browser/App)  | ◄─── 2. HTTP Response ── | (Node/Nginx/…)  |
  +-----------------+                          +-----------------+

The client always speaks first. The server waits, listening on a known address and port (443 for HTTPS), and only ever replies. Clients talk to each other through the server, never directly, and only the server touches the database.

Why build it this way?

• One source of truth. Data and business rules live in one place, so every client (web, Android, iOS) sees the same thing.
• Control and security. The server checks every request before acting on it. A client is any program on someone else’s device and can never be trusted.
• Thin clients. Phones and browsers do not need the whole database or all the logic.

The price is that the server is a bottleneck and a single point of failure (SPOF): if it is slow or down, every client suffers. Real systems therefore run many copies of the server behind a load balancer, which brings its own problems (the next lesson).

#The request–response cycle

Every exchange between client and server follows the same cycle, the HTTP request–response cycle:

1. 1. Request creation

   The user does something (enters a URL, clicks a button) and the client builds an HTTP request. It contains:

   • HTTP method: what the client wants to do (GET = fetch data, POST = send new data, PUT = update, DELETE = remove).
   • URL / endpoint: the exact destination on the server, for example https://api.example.com/users.
   • Headers: extra metadata about the request, for example Content-Type: application/json or Authorization: Bearer <token>.
   • Body (payload): the actual data sent with POST, PUT or PATCH, such as form data or JSON.

2. 2. Network transmission

   The request travels over TCP/IP through routers and ISPs to the server’s IP address and port (443 for HTTPS, 80 for plain HTTP). Before the first byte of HTTP, the client must find the IP (DNS, lesson 1.8) and open a connection (TCP and TLS, lesson 1.9), unless it can reuse one.

3. 3. Server processing

   The server’s router (the code kind, not the network box) looks at the method and path and calls the matching handler. The handler checks who is asking, validates the input, runs the business logic, and reads or writes the database if needed.

4. 4. Response generation

   The server builds an HTTP response:

   • Status code: the outcome (200 OK = success, 201 Created = a new resource was made, 400 Bad Request = the client made a mistake, 401 Unauthorized = authentication needed, 404 Not Found = no such resource, 500 Internal Server Error = the server failed).
   • Headers: metadata from the server, such as Content-Type: text/html or application/json, or Set-Cookie.
   • Body: the actual content: an HTML page, JSON data, an image…

5. 5. Rendering or consumption

   The response returns to the client. A browser renders it and shows it to the user; a mobile app processes the data and updates its screens. A page usually needs more: after reading the HTML, the browser sends further requests for CSS, JavaScript, images and fonts, each its own request–response cycle.

#Anatomy of a URL

A URL (Uniform Resource Locator) tells the client which protocol to speak, which machine to contact, on which port, and which resource to ask for.

https://shop.example.com:443/products/42?color=red&size=m#reviews
└─┬─┘   └──────┬───────┘ └┬┘└────┬────┘ └──────┬───────┘ └──┬──┘
scheme        host      port   path         query       fragment

#Inside an HTTP message

HTTP (Hypertext Transfer Protocol) is the language clients and servers use for web requests and responses. HTTPS (HTTP Secure) is the same HTTP carried inside an encrypted TLS connection, so nobody on the path can read or change it.

In HTTP/1.1 a message is plain text with a fixed shape: a first line, headers, a blank line, then an optional body.

A real request, as it travels in HTTP/1.1:

POST /api/orders HTTP/1.1
Host: shop.example.com
User-Agent: Mozilla/5.0 (…) Chrome/130
Accept: application/json
Content-Type: application/json
Content-Length: 31
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.k3…

{"productId": 42, "quantity": 2}

And the server’s reply:

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 52
Location: /api/orders/981
Cache-Control: no-store

{"id": 981, "productId": 42, "quantity": 2, "paid": false}

The very simplest request a browser makes when you open Google looks like this (simplified):

GET / HTTP/2
Host: www.google.com

HTTP/2 200
content-type: text/html

#HTTP methods

The method says what the client wants to do with the resource named by the URL.

Two words in that table matter enormously in system design:

• Safe: the request does not change anything on the server. Browsers can prefetch it, crawlers can follow it, caches can store the answer.
• Idempotent: doing it once or ten times leaves the server in the same state. That makes it safe to retry after a timeout. Note that the response may differ: a second DELETE returns 404, but the resource is gone either way.

There are two rarer methods you may see in references: CONNECT (asks a proxy to open a tunnel, used for HTTPS through proxies) and TRACE (echoes the request back for debugging, normally disabled for security).

#Status codes

Every response starts with a three-digit status code. The first digit is the class:

The codes you must know:

#Headers you will meet every day

Headers are Name: value lines (names are case-insensitive). The important ones:

You can also invent your own (X-Request-Id for tracing, Idempotency-Key for safe retries). The next lesson is about two of these, Set-Cookie and Cookie, and why they exist at all.

#Connections and HTTP versions

HTTP needs a connection underneath, and opening one is expensive: a TCP handshake costs one round trip, and TLS adds one more (TLS 1.3). The history of HTTP is mostly the story of reusing connections better.

• Keep-alive (persistent connections) avoids a new handshake per request. Servers close idle connections after a timeout to save memory.
• Head-of-line blocking: in HTTP/1.1 a slow response holds up the ones behind it, so browsers open about six connections per host. HTTP/2 fixes this at the HTTP level, but one lost TCP packet still stalls all streams; HTTP/3 fixes that too by using QUIC.
• Clients and servers negotiate the version: HTTP/2 during the TLS handshake (ALPN), HTTP/3 when the server advertises it with an Alt-Svc header. Everything else (methods, status codes, headers) is the same in all versions.

#When things go wrong on the client side

A client must assume the network will fail. The common cases:

The key insight: when a request times out, the client cannot know whether the server never received it or processed it and the answer got lost. That is why:

1. Always set timeouts (a connect timeout and a read timeout). The default in many libraries is “wait forever”.
2. Retry only idempotent requests automatically (GET, PUT, DELETE, HEAD).
3. Make important non-idempotent requests idempotent with an idempotency key: the client sends a unique ID with the request, and the server remembers the result for that ID and replays it instead of doing the work twice.
4. Use exponential backoff with jitter (wait 1 s, 2 s, 4 s… plus randomness) and a maximum number of attempts, so a struggling server is not crushed by a retry storm.

#Client–server in system design

• Most of the internet is client–server. Websites, REST APIs, mobile backends, and the services inside a company calling each other (where one service is the client of another).
• APIs are the contract. Methods, URLs, status codes and headers form the interface between client and server teams. Using them correctly (201 for creation, 409 for conflicts, idempotent PUT) lets proxies, caches and client libraries behave correctly without special code.
• Scaling the server side means many identical servers behind a load balancer. That works smoothly only if any server can answer any request, which is why HTTP being stateless matters so much: next lesson.
• Caching uses the same protocol: Cache-Control, ETag and 304 let browsers and CDNs answer requests without reaching your server at all.
• Failure handling is part of the design: timeouts, retries, idempotency keys and backoff on the client; 503 with Retry-After and rate limits (429) on the server.

#Try it yourself

curl is a command-line HTTP client available on Windows, macOS and Linux.

# See the whole conversation: request headers (>) and response headers (<)
curl -v https://example.com/

# HEAD request: headers only
curl -I https://example.com/

# Follow redirects (-L) and print only the final status code
curl -s -o /dev/null -w "%{http_code}\n" -L http://github.com/

# POST JSON to a test API that echoes back what it received
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"productId": 42, "quantity": 2}'

# Ask for a status code on purpose
curl -i https://httpbin.org/status/404

# Force HTTP/2 or HTTP/3 (if your curl supports it)
curl -sI --http2 https://www.google.com/ | head -1

On Windows PowerShell, use curl.exe instead of curl (the bare name is an alias for a different command). In a browser, open developer tools (F12), go to the Network tab and reload a page: every row is one request–response cycle, with its method, status, headers, size, protocol (h2, h3) and timing.

#Summary

Key takeaways

• In client–server architecture the client asks and the server answers; the server holds the data and logic centrally, and only it talks to the database. It is simple and controllable, but the server is a bottleneck and a single point of failure.
• The request–response cycle: create the request (method, URL, headers, body) → transmit over TCP/IP → server routes, validates, runs logic → builds a response (status, headers, body) → client renders it. One page usually means many cycles.
• A URL is scheme + host + port + path + query + fragment; the fragment never reaches the server, and secrets never belong in the URL.
• Methods: GET/HEAD/OPTIONS are safe; GET, HEAD, OPTIONS, PUT and DELETE are idempotent; POST is neither, PATCH is not guaranteed. Idempotent means safe to retry.
• Status codes: 2xx success, 3xx redirect or cached (301, 302, 304), 4xx client error (400, 401 unauthenticated, 403 forbidden, 404, 409, 429), 5xx server error (500 code bug, 502/504 from the proxy, 503 temporary).
• Connections: HTTP/1.1 keep-alive reuses a connection one request at a time; HTTP/2 multiplexes; HTTP/3 uses QUIC so packet loss only delays one stream.
• Clients must handle failure: timeouts always, retries with backoff and jitter, and idempotency keys for anything that must not happen twice.

Self-check: client–server and HTTP31 questions