HTTP 101: Guide from engineering point of view
HTTP (Hypertext Transfer Protocol) is the lifeline of web communication, powering everything from simple page loads to complex API interactions. For backend engineers, a solid grasp of HTTP's core concepts is non-negotiable.
HTTP (Hypertext Transfer Protocol) is the lifeline of web communication, powering everything from simple page loads to complex API interactions. For backend engineers, a solid grasp of HTTP's core ideas—headers, methods, CORS, status codes, caching, and transport security—is non‑negotiable.
Why it matters
Every REST API, webhook, or browser request you ship rides on HTTP. Knowing the protocol keeps debugging grounded and architecture decisions predictable.
1. What is HTTP?
HTTP lives at the application layer and defines how clients (browsers, mobile apps, CLIs) talk to servers. The protocol is stateless: each request carries everything the server needs, so scaling horizontally becomes easier. The tradeoff is that any notion of “session” or “user identity” must be carried with explicit tokens, cookies, or headers.
2. Headers: Metadata That Drives Everything
Headers are key/value pairs attached to requests and responses. They describe the payload, control caching, enable authentication, and let us ship new capabilities without changing the core protocol.
Key header families
- Request headers:
User-Agent,Authorization,Accept. - General headers:
Cache-Control,Connection. - Representation headers:
Content-Type,Content-Length,ETag. - Security headers:
Strict-Transport-Security,Content-Security-Policy.
Why headers matter
Headers let you layer authentication, compression, tracing, or feature flags without mutating the request body. They’re infinitely extensible, so teams can innovate without waiting for protocol changes.
3. HTTP Methods & Idempotency
Methods describe the intent of a request. Knowing which ones should be idempotent keeps APIs predictable and cache-friendly.
- GET: Retrieve data; must not mutate state (idempotent).
- POST: Create new data; can produce different results each call (non-idempotent).
- PUT: Replace an entire resource; safe to repeat (idempotent).
- PATCH: Partially update a resource; typically treated as idempotent.
- DELETE: Remove a resource; repeating it shouldn’t change the outcome.
- OPTIONS: Ask the server which methods/headers are allowed—critical for CORS preflight.
Idempotency means repeating the same request won’t change state after the first success. GET/PUT/DELETE lean on this guarantee for retries and caching.
4. CORS (Cross-Origin Resource Sharing)
CORS is the browser’s guardrail that prevents malicious pages from hitting your APIs. Browsers enforce the same-origin policy by default; CORS lets servers poke holes in that wall safely.
How it works
The browser sends an Origin header. Your server must reply with Access-Control-Allow-Origin (a specific domain or *) before the browser will expose the response to client code.
Simple vs preflight
- Simple requests (GET, POST, HEAD with basic headers) go straight through; the browser just inspects the response headers.
- Preflighted requests (PUT, DELETE, or any request with custom headers like
Authorization) trigger an automatic OPTIONS call. The server must respond with allowed methods/headers before the real request is sent.
Key headers: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials.
Get these right and you balance usability (mobile apps, partner portals) with safety.
5. Reading HTTP Response Codes
Status codes are the protocol’s native language for expressing success, redirects, client mistakes, or server failures.
Success & redirects
- 200 OK: Everything worked.
- 201 Created: Resource created (often with a Location header).
- 204 No Content: Success with no body.
- 301/302: Permanently or temporarily moved.
- 304 Not Modified: Use your cached copy.
Client & server issues
- 400 Bad Request: Payload or syntax problem.
- 401/403: Authentication vs authorization failures.
- 404 Not Found: The resource doesn’t exist.
- 409 Conflict: State mismatch (versioning, duplicates).
- 429 Too Many Requests: Rate limiting kicked in.
- 500/502/503/504: Server blew up, bad gateway, temporarily down, or upstream timeout.
Use these codes consistently so clients can automate retries, fallbacks, or user messaging.
6. HTTP Caching Essentials
Caching trims latency and cost by serving responses from nearby storage when nothing has changed.
- Cache-Control: The rulebook—
max-age,no-store,public, etc. - ETag: A version hash so clients can ask “has this changed?” via conditional requests.
- Last-Modified: Timestamp alternative to ETag; handy for coarse invalidation.
Browsers/CDNs compare these headers to decide whether to reuse a response or fetch it again, cutting bandwidth and speeding up UI.
7. SSL, TLS, and HTTPS
SSL
Secure Sockets Layer—The original encryption protocol for HTTP. Obsolete today but historically important.
TLS
Transport Layer Security—the modern successor. It encrypts and authenticates traffic so eavesdroppers can’t read or tamper with data.
HTTPS
HTTP over TLS (or legacy SSL). Any https:// URL means the connection is encrypted, authenticated, and far safer for credentials or payments.
Conclusion
Mastering HTTP’s stateless model, headers, verbs, CORS, status codes, caching, and transport security gives you leverage everywhere—from debugging flaky requests to designing resilient APIs. Nail the fundamentals and every backend system you touch becomes easier to reason about.