HTTP & Web Protocols: Methods, Status Codes & HTTP/2/3

Q: What's the difference between safe and idempotent methods?

A safe method doesn't change server state — GET, HEAD, and OPTIONS just read, so calling them has no side effects. An idempotent method produces the same result whether called once or many times — GET, PUT, and DELETE are idempotent (deleting an already-deleted resource leaves it deleted; replacing with PUT twice yields the same state), while POST is not (two POSTs may create two resources). These properties matter practically: safe methods can be cached and prefetched freely, and idempotent methods can be safely retried after a network failure without risking duplicate effects.

Q: What's the difference between HTTP/1.1, HTTP/2, and HTTP/3?

HTTP/1.1 sends requests largely one-at-a-time per connection, suffering head-of-line blocking and needing many parallel connections. HTTP/2 multiplexes many concurrent requests over a single connection and compresses headers, dramatically improving performance for resource-heavy pages. HTTP/3 keeps HTTP/2's benefits but runs over QUIC (built on UDP instead of TCP), which eliminates TCP-level head-of-line blocking, establishes connections faster, and handles network changes (like switching from Wi-Fi to cellular) gracefully. The semantics — methods, status codes, headers — are the same across a

HTTP & Web Protocols

HTTP (HyperText Transfer Protocol) is the language of the web — every page load, API call, and asset fetch is an HTTP request and response. Understanding it deeply is foundational for anyone building web software: it governs how clients and servers communicate, what methods and status codes mean, how headers carry metadata, and why the web's statelessness shapes everything from authentication to caching. You can build for years on top of HTTP without understanding it, but the moment something breaks — a confusing status code, a caching bug, a CORS error — that understanding becomes essential.

The core model is beautifully simple: a client sends a request (method + URL + headers + optional body), the server returns a response (status code + headers + optional body), and the connection is stateless — each request stands alone, carrying everything it needs. Everything else (REST APIs, cookies, caching, auth) is built on this foundation. This page covers the protocol itself; for designing APIs over it, see REST API Design.

TL;DR

HTTP is a stateless request/response protocol — the foundation of the web.
Methods (GET/POST/PUT/DELETE) state intent; status codes state the outcome.
Headers carry metadata (content type, auth, caching); the body carries data.
HTTPS = HTTP over TLS; HTTP/2 and HTTP/3 improve performance over HTTP/1.1.

Quick Example

A request and its response — the whole protocol in miniature:

The Request/Response Model

Request — a method (the intent), a URL/path (the resource), headers (metadata), and an optional body (data sent to the server).
Response — a status code (the outcome), headers (metadata), and an optional body (data returned).
Stateless — the server doesn't remember previous requests; each request carries everything needed (which is why auth tokens and cookies are re-sent every time).

Methods

Safe = doesn't change server state; idempotent = repeating it has the same effect as doing it once (matters for retries).

Status Codes

The first digit signals the category:

2xx Success — 200 OK, 201 Created, 204 No Content.
3xx Redirection — 301 Moved Permanently, 304 Not Modified (caching).
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.

💡 Use the right status code — 200 with an error in the body, or 500 for a client mistake, breaks clients, caching, and monitoring that rely on accurate codes.

Headers, HTTPS & Evolution

Headers carry metadata: Content-Type, Authorization, Cache-Control, Accept, CORS headers, and more. They drive content negotiation, auth, and caching.
HTTPS is HTTP over TLS — encrypting traffic so it can't be read or tampered with in transit. Now the default for the entire web. See HTTPS & TLS.
HTTP/1.1 → HTTP/2 → HTTP/3 — HTTP/2 added multiplexing (many requests over one connection, fixing head-of-line blocking) and header compression; HTTP/3 runs over QUIC (UDP-based) for faster, more resilient connections, especially on mobile.

Best Practices

Use the correct method and status code — they carry meaning clients and tools depend on.
Always use HTTPS — encryption is non-negotiable for any real traffic.
Set caching headers deliberately (Cache-Control, ETag) — see Caching.
Design idempotent operations (PUT/DELETE) so retries are safe.
Don't put sensitive data in URLs — they're logged; use headers/body.

Common Mistakes

Wrong status codes

Using GET to change state

FAQ

What does it mean that HTTP is "stateless"?

It means each request is independent — the server doesn't inherently remember anything about previous requests from the same client. Every request must carry all the context the server needs to handle it (which is why authentication tokens or session cookies are sent on every request, not just once at login). Statelessness makes HTTP simple and scalable (any server can handle any request, enabling load balancing), but it's why "state" — login sessions, shopping carts — must be explicitly managed via cookies, tokens, or server-side stores rather than being remembered by the connection itself.

What's the difference between safe and idempotent methods?

A safe method doesn't change server state — GET, HEAD, and OPTIONS just read, so calling them has no side effects. An idempotent method produces the same result whether called once or many times — GET, PUT, and DELETE are idempotent (deleting an already-deleted resource leaves it deleted; replacing with PUT twice yields the same state), while POST is not (two POSTs may create two resources). These properties matter practically: safe methods can be cached and prefetched freely, and idempotent methods can be safely retried after a network failure without risking duplicate effects.

What's the difference between HTTP/1.1, HTTP/2, and HTTP/3?

HTTP/1.1 sends requests largely one-at-a-time per connection, suffering head-of-line blocking and needing many parallel connections. HTTP/2 multiplexes many concurrent requests over a single connection and compresses headers, dramatically improving performance for resource-heavy pages. HTTP/3 keeps HTTP/2's benefits but runs over QUIC (built on UDP instead of TCP), which eliminates TCP-level head-of-line blocking, establishes connections faster, and handles network changes (like switching from Wi-Fi to cellular) gracefully. The semantics — methods, status codes, headers — are the same across all three; what changes is how efficiently data moves over the wire.

When should I use which HTTP status code?

Match the code to the actual outcome so clients and tooling behave correctly. Use 2xx for success (200 general, 201 created, 204 no content). Use 3xx for redirects and caching (301 permanent move, 304 not modified). Use 4xx when the client erred — 400 malformed request, 401 not authenticated, 403 authenticated but forbidden, 404 not found, 429 rate-limited. Use 5xx when the server failed — 500 general error, 503 temporarily unavailable. The cardinal rule: never return 200 for an error or a 5xx for a client mistake, because caches, monitoring, and clients all rely on accurate codes.