HTTP stands for HyperText Transfer Protocol. It is the foundational communication protocol of the World Wide Web — the set of rules that defines how a client (like a browser or an app) and a server exchange messages over a network.
Every time I type a website address into my browser, or every time an app calls a Web API, HTTP is the language being used underneath. In this article, I want to break down exactly how it works, piece by piece.
How an HTTP Request Works
An HTTP interaction always follows a request-response pattern:
1. The client sends a request
This request includes:
- A method (like
GET,POST,PUT,DELETE) that describes the desired action. - A URL that identifies the resource being requested.
- Headers — extra metadata, like what content type the client accepts, or an authentication token.
- Sometimes a body — actual data being sent, such as a new user’s information in JSON format.
2. The server processes the request and sends back a response
The response includes:
- A status code — a three-digit number telling the client what happened.
- Headers — metadata about the response, like the content type of the returned data.
- A body — the actual data returned, often in JSON format for Web APIs.
That’s really the whole model. Every single HTTP exchange, no matter how complex the app, boils down to this same request-then-response pattern.
The Most Common HTTP Methods
| Method | Typical purpose |
|---|---|
GET | Retrieve data without changing anything |
POST | Create a new resource, or submit data |
PUT | Replace an existing resource entirely |
PATCH | Update part of an existing resource |
DELETE | Remove a resource |
HEAD | Like GET, but only returns headers, no body |
OPTIONS | Ask the server what methods/actions are allowed on a resource |
Common HTTP Status Codes
Status codes are grouped into categories based on their first digit:
| Range | Meaning | Common examples |
|---|---|---|
| 1xx | Informational | 100 Continue |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 304 Not Modified |
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | Server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
I’ve found understanding these codes essential — whether I’m debugging why an app isn’t working, or probing an API and noticing an unexpected 500 error that might hint at a bug worth investigating further. Status codes are often the very first clue about what’s actually happening on the server side, before I even look at the response body.
A few I pay close attention to regularly:
401 Unauthorized— means authentication is missing or invalid; I haven’t proven who I am.403 Forbidden— means I am authenticated, but I’m not allowed to access this particular resource.429 Too Many Requests— means I’ve hit a rate limit, and I need to slow down.500 Internal Server Error— means something broke on the server’s side, unrelated to what I sent.
HTTP Headers Worth Knowing
Headers carry metadata alongside the actual request or response body. A few common ones:
Content-Type— tells the receiver what format the body is in (likeapplication/json).Authorization— carries credentials, like a Bearer token or API key.Cache-Control— tells clients and intermediaries how (or whether) to cache a response.User-Agent— identifies what kind of client is making the request (a browser, an app, a script).
HTTP vs HTTPS
HTTPS is simply HTTP wrapped inside an encrypted connection using TLS (Transport Layer Security). Without HTTPS, data sent over HTTP — like passwords, session tokens, or personal information — travels across the network in plain, readable text, meaning anyone intercepting the traffic (on public Wi-Fi, for example) could read it.
Nearly all modern Web APIs require HTTPS, and browsers now actively warn users when a site only uses plain HTTP. If I ever see an API that still accepts plain HTTP connections for sensitive operations, that’s an immediate red flag worth investigating further.
HTTP Is Stateless by Design
HTTP itself is a stateless protocol — each request is treated as brand new, with no built-in memory of previous requests. This is exactly why REST and HTTP fit together so naturally; REST’s statelessness constraint is really just embracing HTTP’s own natural design rather than fighting against it.
Any “state” I experience on a website, like staying logged in, is actually built on top of HTTP using techniques like cookies or authentication tokens sent with every single request. The protocol itself never “remembers” me — the application layer built on top of it does, by making sure the right identifying information rides along with each new request.
HTTP Versions Worth Knowing About
HTTP has evolved over the years:
- HTTP/1.1 — the long-standing version most people are familiar with, sending one request per connection at a time (with some optimizations).
- HTTP/2 — introduced multiplexing, allowing multiple requests and responses to travel over a single connection at once, improving speed.
- HTTP/3 — built on a newer transport protocol called QUIC instead of traditional TCP, further reducing latency, especially on unreliable networks.
The core request-response model and status codes stay conceptually the same across all these versions — what changes is mostly the underlying performance and connection handling.
Final Thoughts
HTTP is the quiet, foundational layer underneath almost everything I do online. Once I understood its request-response structure, its methods, and its status codes properly, reading network traffic, debugging broken API calls, and even doing security testing all became far more intuitive, because I finally understood the actual language being spoken underneath every single request.