Every time you type an address in the browser and hit Enter, a fascinating sequence of events happens in milliseconds. Understanding this flow is the foundation of everything in the back-end: APIs, authentication, caching and scalability are all just variations of this same model. If you master request and response, you master the rest.

The client-server model

The web works with two roles: the client (your browser, an app, a script) makes requests, and the server responds to them. The client never "gets inside" the server — it just sends a message asking for something and waits for a response. This conversation happens using the HTTP protocol (HyperText Transfer Protocol).

A good analogy is ordering food at a restaurant. You (the client) place an order with the waiter (the request). The kitchen (the server) processes it. The waiter comes back with the dish or with a "we're out of that ingredient" (the response). You don't walk into the kitchen: you just send orders and receive responses.

What happens between the URL and the page

When you visit https://example.com/products, several steps happen in order:

1. DNS    -> "example.com" becomes an IP (e.g. 93.184.216.34)
2. TCP    -> client opens a connection to the server at that IP
3. TLS    -> encryption handshake (the "s" in https)
4. HTTP   -> client sends the request: GET /products
5. Server -> processes it (queries the database, builds the response)
6. HTTP   -> server returns the response: 200 OK + HTML/JSON
7. Render -> browser draws the page

DNS is the internet's "contact book": it translates readable names into IP addresses. TCP establishes a reliable channel between client and server, and TLS encrypts it. Only then does the HTTP request actually travel.

Anatomy of a request

An HTTP request has four parts. In interviews you're often asked to describe them:

• Method (verb): what you want to do — GET (read), POST (create), PUT/PATCH (update), DELETE (remove).
• Path: which resource — /products, /users/42.
• Headers: metadata — content type, authentication, language.
• Body: the data sent (in POST/PUT), usually as JSON. GET normally has no body.

POST /products HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123

{ "name": "Keyboard", "price": 350 }

Anatomy of a response

The response has three parts: the status code, the headers and the body. The status sums up what happened, grouped into families: 2xx success, 3xx redirection, 4xx client error, 5xx server error.

HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 42, "name": "Keyboard", "price": 350 }

Why HTTP is stateless

HTTP is stateless: the server doesn't remember you between one request and the next. Each request has to carry everything the server needs to understand it. It's like calling a support center where every call lands on a different agent who has no record of your history — you have to identify yourself every time.

This looks like a limitation, but it's what makes scaling possible: since no server keeps track of "where you were", any server can handle any request. State (who you are, your cart) is kept elsewhere, through cookies, tokens or a database — the subject of authentication and authorization.

The whole web is a request-and-response conversation over a protocol with no memory. Understanding request, response and why stateless matters is the foundation of everything else in the back-end.

Conclusion

From DNS to render, every visit is an exchange of messages between client and server over HTTP. Knowing how to dissect a request (method, path, headers, body) and a response (status, headers, body), and understanding why HTTP is stateless, is the knowledge that underpins REST APIs, sessions and scalability. Master this flow and you'll have the map for everything that comes after.