HTTP request & response

Every time you load a web page, your browser and a server hold a brief, structured conversation. That conversation follows HTTP, the Hypertext Transfer Protocol — the request-and-response language that underpins the entire web. Understanding its anatomy demystifies almost everything that happens between clicking a link and seeing a page, and it is the foundation for working with APIs of every kind.

The shape of a request

An HTTP exchange always begins with a client sending a request to a server. A request has three parts. The first line names a method, a target path, and the protocol version, for example GET /articles/42 HTTP/1.1. After that come headers, which are key-value pairs of metadata. Finally there is an optional body, used when the client needs to send data such as form contents or a JSON payload.

The method announces intent. The most common ones are:

• GET — retrieve a resource. It is safe, meaning it should not change anything on the server, and its responses can be cached.
• POST — submit data, often to create something or trigger processing. It is neither safe nor idempotent.
• PUT — replace a resource entirely at a known location.
• DELETE — remove a resource.

PUT and DELETE are idempotent: sending the same request twice leaves the server in the same final state as sending it once. This distinction matters for reliability — a client can safely retry an idempotent request after a network hiccup, but retrying a POST might create a duplicate order.

The shape of a response

The server answers with a response built from the same three ingredients. Its first line is the status line, carrying the version, a numeric status code, and a short reason phrase such as 200 OK. Then come headers, and usually a body holding the actual content — HTML, JSON, an image, and so on.

Status codes are grouped into five classes by their leading digit, and knowing the classes lets you diagnose almost any response at a glance:

• 1xx Informational — the request was received and processing continues.
• 2xx Success — the request succeeded. 200 OK is the everyday case.
• 3xx Redirection — the resource lives elsewhere; follow the provided location.
• 4xx Client Error — the request was faulty. 404 Not Found means the path matched nothing; 403 Forbidden means access was denied.
• 5xx Server Error — the request was valid but the server failed. 500 Internal Server Error is the classic.

A useful mental shortcut: 4xx is “you made a mistake,” 5xx is “I made a mistake.”

Headers: the metadata layer

Headers carry information about the message rather than the message itself. They are enormously versatile. Content-Type declares the media type of the body — text/html, application/json, image/png — so the recipient knows how to parse it. Content-Length gives the body’s size. Caching headers control how long a response may be reused. Authentication headers carry tokens, and Set-Cookie and Cookie headers carry the small pieces of state that make sessions possible.

That last point hints at a defining property of the protocol.

Statelessness: every request stands alone

HTTP is stateless. By default, the server keeps no memory of previous requests; each one arrives as an independent event with no built-in connection to what came before. This is a deliberate design choice that makes servers simpler and easier to scale — any server in a pool can handle any request without needing to know its history.

But real applications obviously do remember you across requests, so how? The trick is that any continuity must be carried explicitly in the messages themselves. After you log in, the server hands your browser a cookie or token; your browser attaches it to every subsequent request, and the server uses it to recognize you anew each time. The protocol stays stateless even while the application built on top of it feels stateful.

Why the anatomy matters

Once you see HTTP as method plus headers plus body answered by status plus headers plus body, the whole web becomes legible. Debugging a broken page, designing an API, configuring a cache, or securing a login all come down to reading and shaping these same few fields. It is a small vocabulary, and learning it pays off in nearly every corner of software.