How HTTP Works: The Protocol Behind Every Backend

Before APIs, databases, or deployment, there's one thing every backend speaks: HTTP. It's the protocol your browser uses to load this page and the language nearly every API talks in. The good news is that at its core it's almost trivially simple — a request goes out, a response comes back — and that simplicity is worth understanding precisely, because everything else in backend builds on it.

A request and a response

HTTP is a client-server conversation. A client (a browser, a mobile app, another server) sends a request; a server sends back a response. That's the entire model.

Client sends request

↓→

Server processes it

↓→

Server sends response

A request says four things: which method (the verb), what resource (the URL/path), some headers (metadata), and optionally a body (data). A response says: a status code (how it went), some headers, and usually a body (the result). Learn those parts and you can read any HTTP traffic.

Methods: the verb of the request

The method declares your intent. A handful cover almost everything:

Method	Means	Example
GET	Read data	Fetch a user's profile
POST	Create something	Submit a new order
PUT / PATCH	Update something	Edit a profile (replace / partially)
DELETE	Remove something	Delete an account

The method matters beyond labeling. GET should never change anything (it's "safe"), and GET/PUT/DELETE are idempotent — doing them twice has the same effect as once. These conventions are what let browsers, caches, and proxies treat requests correctly, and they become the backbone of REST.

Status codes: how it went

The server's response opens with a three-digit status code, grouped by first digit:

Range	Meaning	Common ones
2xx	Success	200 OK, 201 Created
3xx	Redirect	301 Moved, 304 Not Modified
4xx	Client error	400 Bad Request, 401 Unauthorized, 404 Not Found
5xx	Server error	500 Internal Error, 503 Unavailable

Headers: metadata around the message

If the body is the cargo, headers are the shipping label. They carry information about the message without being part of the data:

• Content-Type — what format the body is (e.g. JSON).
• Authorization — credentials proving who you are.
• Cache-Control — whether and how the response may be cached.

Headers appear on both requests and responses, and a huge amount of backend behavior — authentication, caching, content negotiation — is coordinated through them.

HTTP is stateless

Here's the property that quietly shapes everything downstream: HTTP is stateless. Each request is independent, and the server remembers nothing about you between requests by default. The second request has no idea the first one happened.

That's great for scaling — any server can handle any request, since none of them hold special memory of you — but it raises an obvious problem: if the server forgets you after every request, how does it know you're logged in on the next one?

Why this is the foundation

It's tempting to skip straight to frameworks, but nearly every backend concept is a convention on top of HTTP. REST is a discipline for using methods and status codes well. GraphQL is a different shape of request body over the same protocol. Authentication is headers carrying identity. Caching is headers negotiating freshness. Once HTTP's request-response-stateless model is solid in your head, those topics become variations on a theme you already know.

Recap

• HTTP is a client-server protocol: a request goes out, a response comes back.
• The method (GET, POST, PUT/PATCH, DELETE) declares intent; GET is safe, several methods are idempotent.
• Status codes summarize the outcome — 2xx success, 3xx redirect, 4xx your error, 5xx server error.
• Headers carry metadata (content type, auth, caching) around the message body.
• HTTP is stateless — the server forgets you between requests, which is why sessions and tokens exist.

We can move requests and responses. But a request needs something to talk to — a defined interface for one program to call another. That's an API. Continue to What Is an API?.