HTTP FOR BACKEND

ENGINEERS
Where It All Starts
Complete Class Notes to Crack High-Paying Offers

Topics: HTTP Basics | Methods | Status Codes | Headers | HTTPS/TLS | HTTP/2 & HTTP/3 |
REST | Caching | Auth | WebSockets
1. What is HTTP? — The Foundation
HTTP (HyperText Transfer Protocol) is the backbone of all web communication. Every app you build
as a backend engineer relies on it.

1.1 Definition & Core Idea

• HTTP is an application-layer protocol for transmitting hypermedia documents (HTML,
JSON, XML, images, etc.)
• It is a request-response protocol: the client sends a request, the server sends back a
response.
• HTTP is stateless — each request is independent; the server does NOT remember
previous requests.
• It runs on top of TCP/IP (or QUIC for HTTP/3).

1.2 How the Web Works — The Big Picture

Understanding the full flow from typing a URL to seeing a response is an interview favorite.
Step-by-step flow of what happens when you type [Link]
• Step 1: DNS Resolution
○ Your OS checks its local DNS cache first.
○ If not found, it queries a DNS resolver (usually your ISP or [Link]).
○ DNS resolves the domain to an IP address (e.g., [Link]).
• Step 2: TCP Connection (3-way Handshake)
○ Client sends SYN → Server replies SYN-ACK → Client sends ACK
○ This establishes a reliable connection before any data is sent.
• Step 3: TLS Handshake (for HTTPS)
○ Client and server negotiate cipher suite, exchange certificates, create session keys.
• Step 4: HTTP Request is sent
○ Client sends the HTTP request over the established connection.
• Step 5: Server Processes & Responds
○ Server processes the request, queries DB if needed, and sends an HTTP response.
• Step 6: Browser/Client Renders
○ Client receives response, parses it, and renders/uses the data.

Interview Tip: Interviewers LOVE asking 'What happens when you type a URL?' — know all 6
steps cold.
2. HTTP Request & Response Structure
Knowing the exact anatomy of HTTP messages separates junior devs from senior backend
engineers.

2.1 HTTP Request Structure

An HTTP request consists of 3 parts:

Part 1 — Request Line:

METHOD /path/to/resource HTTP/1.1
Example: GET /api/users/123 HTTP/1.1

Part 2 — Headers:
Host: [Link]
Content-Type: application/json
Authorization: Bearer eyJhbGci...
Accept: application/json

Part 3 — Body (optional, used in POST/PUT/PATCH):

{
"name": "John",
"email": "john@[Link]"
}

2.2 HTTP Response Structure

Part 1 — Status Line:
HTTP/1.1 200 OK

Part 2 — Headers:
Content-Type: application/json
Content-Length: 348
Cache-Control: max-age=3600

Part 3 — Body:
{ "id": 123, "name": "John" }
3. HTTP Methods (Verbs)
HTTP methods define what action the client wants to perform. Mastering these is essential for REST
API design.

Method Purpose Has Idempoten Safe?

Body? t?

GET Retrieve a resource No Yes Yes

POST Create a new resource Yes No No
PUT Replace a resource Yes Yes No
entirely
PATCH Partially update a Yes No No
resource
DELETE Delete a resource Optional Yes No
HEAD GET but no response No Yes Yes
body
OPTIONS Describe communication No Yes Yes
options (CORS preflight)

3.1 Key Concepts for Interviews

• Idempotent: Making the SAME request multiple times produces the same result. GET,
PUT, DELETE are idempotent.
• Safe: Does NOT modify server state. GET, HEAD, OPTIONS are safe.
• POST is neither safe nor idempotent — sending POST twice may create two resources.
• PUT vs PATCH: PUT replaces the entire resource. PATCH only updates specific fields.

Interview Tip: Why is DELETE idempotent? Deleting a resource that no longer exists still results
in 'no resource' — same outcome.
Common Mistake: Using GET for operations that change state (e.g., GET /deleteUser/123) is a
design anti-pattern.

4. HTTP Status Codes

Status codes tell the client exactly what happened on the server. Using them correctly is a mark of a
senior engineer.

Range Category Meaning

1xx Informational Request received, processing continues

 Range Category Meaning

2xx Success Request was successfully received and processed

3xx Redirection Further action is needed to complete the request
4xx Client Error The request contains bad syntax or cannot be fulfilled
5xx Server Error The server failed to fulfill a valid request

4.1 Critical Status Codes to Know

2xx — Success:
• 200 OK — Standard success response for GET, PUT, PATCH
• 201 Created — Resource successfully created (POST). Include Location header with
new resource URL.
• 204 No Content — Success but no body (common for DELETE)

3xx — Redirects:
• 301 Moved Permanently — Resource has new URL. Browser caches this redirect
forever.
• 302 Found — Temporary redirect. Browser does NOT cache.
• 304 Not Modified — Cached version is still valid (used with ETags/Last-Modified)

4xx — Client Errors:

• 400 Bad Request — Malformed syntax, invalid JSON, missing required fields
• 401 Unauthorized — Not authenticated. Must include credentials.
• 403 Forbidden — Authenticated but NOT authorized to access this resource
• 404 Not Found — Resource does not exist
• 405 Method Not Allowed — You used wrong HTTP method (e.g., POST on read-only
endpoint)
• 409 Conflict — Resource already exists (e.g., duplicate email on signup)
• 422 Unprocessable Entity — Semantically incorrect data (passes parsing but fails
validation)
• 429 Too Many Requests — Rate limiting in action

5xx — Server Errors:

• 500 Internal Server Error — Generic unhandled exception on server
• 502 Bad Gateway — Server acting as proxy received invalid response from upstream
• 503 Service Unavailable — Server is down or overloaded (include Retry-After header)
• 504 Gateway Timeout — Upstream server did not respond in time

Interview Tip: 401 vs 403: 401 = 'Who are you?' (not logged in). 403 = 'I know who you are, but
NO.' (logged in but no permission).
5. HTTP Headers — Deep Dive
Headers carry metadata about the request/response. They control caching, auth, content
negotiation, security, and more.

5.1 Common Request Headers

Header Purpose Example

Host Target domain (required in Host: [Link]

HTTP/1.1)
Content-Type MIME type of request body Content-Type: application/json
Accept What response formats client Accept: application/json, text/html
accepts
Authorization Credentials for authentication Authorization: Bearer <token>
User-Agent Identifies the client software User-Agent: Mozilla/5.0...
Cookie Send stored cookies to server Cookie: session=abc123
If-None-Match Conditional request using ETag If-None-Match: "abc123"
If-Modified-Since Conditional request by date If-Modified-Since: Fri, 01 Jan 2024...
Accept-Encoding Supported compression methods Accept-Encoding: gzip, deflate, br
Origin Origin of cross-site request Origin: [Link]
(CORS)

5.2 Common Response Headers

Header Purpose Example

Content-Type MIME type of response body Content-Type: application/json;

charset=utf-8
Cache-Control Caching directives Cache-Control: max-age=3600, public
ETag Version identifier for caching ETag: "abc123def456"
Location Redirect target / new resource Location: /api/users/456
URL
Set-Cookie Set a cookie on the client Set-Cookie: session=xyz; HttpOnly;
Secure
WWW-Authenticate Auth challenge on 401 WWW-Authenticate: Bearer realm="api"
Access-Control-Allow- CORS — who can access Access-Control-Allow-Origin: *
Origin
 Header Purpose Example

X-RateLimit-Limit Rate limit maximum X-RateLimit-Limit: 1000

X-RateLimit-Remaining Remaining requests X-RateLimit-Remaining: 42
Retry-After When to retry after 429/503 Retry-After: 60

6. HTTPS & TLS — How Security Works

Every production backend uses HTTPS. Understanding TLS at a conceptual level is critical for
senior interviews.

6.1 Why HTTPS?

• HTTP sends data in plain text — anyone on the network can read it (man-in-the-middle
attack).
• HTTPS = HTTP + TLS (Transport Layer Security). It provides:
○ Encryption: data is unreadable to eavesdroppers
○ Authentication: server proves its identity via SSL certificate
○ Integrity: data cannot be tampered with in transit

6.2 TLS Handshake (Simplified)

How client and server establish a secure connection:
• Client Hello — Client sends supported TLS versions & cipher suites.
• Server Hello — Server selects TLS version and cipher suite, sends its SSL certificate.
• Certificate Verification — Client verifies the certificate with a Certificate Authority (CA).
• Key Exchange — Client and server generate shared session keys (using asymmetric
crypto like RSA or ECDHE).
• Secure Communication — All further communication uses the symmetric session key
(fast).

Key Concept: Asymmetric encryption (RSA) is used ONLY during the handshake to securely
exchange keys. The actual data transfer uses fast symmetric encryption (AES).

6.3 SSL Certificates

• A certificate binds a domain name to a public key and is signed by a trusted CA (e.g.,
Let's Encrypt, DigiCert).
• Your browser has a list of trusted CAs — if the server's cert is signed by one, it's trusted.
• Self-signed certificates are fine for development but browsers will show warnings in
production.
7. HTTP Versions: 1.0 → 1.1 → 2 → 3
HTTP has evolved significantly. Knowing the differences shows deep understanding of performance
and networking.

7.1 HTTP/1.0
• One TCP connection per request — extremely inefficient.
• Connection closed after every response.
• No persistent connections, no pipelining.

7.2 HTTP/1.1 (Most common today)

• Persistent connections (Connection: keep-alive) — one TCP connection for multiple
requests.
• Pipelining — send multiple requests without waiting for responses (rarely used in
practice due to HOL blocking).
• Chunked Transfer Encoding — send data in chunks (useful for streaming).
• Host header became mandatory — enabling virtual hosting (multiple domains on one
server).
• Problem: Head-of-Line (HOL) Blocking — if one request is slow, it blocks all others on
the same connection.

7.3 HTTP/2
• Multiplexing — multiple requests/responses in parallel over a SINGLE TCP connection.
Solves HOL blocking at HTTP layer.
• Binary protocol — messages are binary frames instead of text (faster parsing).
• Header compression (HPACK) — compresses repeated headers, significantly reducing
overhead.
• Server Push — server can proactively send resources to client before they're requested.
• Still has TCP-level HOL blocking — if one TCP packet is lost, everything waits.

7.4 HTTP/3 (Latest)

• Runs on QUIC (Quick UDP Internet Connections) instead of TCP — solves TCP HOL
blocking.
• QUIC builds connection reliability + TLS encryption into the transport layer itself.
• Faster connection setup (0-RTT / 1-RTT) compared to TCP + TLS separately.
• Better performance on lossy networks (mobile, poor WiFi).
• Currently adopted by major platforms: Google, Facebook, Cloudflare.
 Feature HTTP/1.1 HTTP/2 HTTP/3

Protocol Text-based Binary frames Binary (QUIC)

Connections Multiple TCP Single TCP Single QUIC (UDP)
Multiplexing No (pipelining) Yes Yes
HOL Blocking Yes (HTTP + TCP) TCP level only No
Header Compression None HPACK QPACK
TLS Optional Required (in Built into QUIC
practice)

8. REST API Design Principles

REST (Representational State Transfer) is the dominant architectural style for web APIs. Know this
inside-out.

8.1 The 6 Constraints of REST

• Client-Server: Separation of concerns between UI and data storage.
• Stateless: Each request must contain ALL info needed to process it. No session state on
server.
• Cacheable: Responses must define themselves as cacheable or non-cacheable.
• Uniform Interface: Consistent resource identification via URIs.
• Layered System: Client can't tell if it's talking to the actual server or an intermediary
(load balancer, cache).
• Code on Demand (optional): Servers can send executable code (e.g., JavaScript) to
clients.

8.2 RESTful URL Design Best Practices

Good URL Design Rules:
• Use nouns (resources), NOT verbs in URLs:
○ GOOD: GET /api/users/123
○ BAD: GET /api/getUser?id=123
• Use plural nouns: /users, /products, /orders
• Use hierarchy to express relationships: GET /users/123/orders
• Use query params for filtering/sorting/pagination: GET /users?
role=admin&page=2&limit=20
• Versioning in URL: /api/v1/users OR in header: Accept:
application/[Link]+json;version=1
 Action HTTP Method URL Status Code

Get all users GET /api/v1/users 200 OK

Get one user GET /api/v1/users/:id 200 OK / 404
Create user POST /api/v1/users 201 Created
Update user PUT /api/v1/users/:id 200 OK
Partial update PATCH /api/v1/users/:id 200 OK
Delete user DELETE /api/v1/users/:id 204 No Content

9. HTTP Caching — Boost Performance

Caching is one of the most impactful performance optimizations. Senior engineers must understand
it deeply.

9.1 Why Cache?

• Reduces latency — serve from cache instead of hitting DB or upstream server.
• Reduces server load — fewer requests reach your backend.
• Saves bandwidth — no need to retransmit unchanged data.

9.2 Cache-Control Header

The primary mechanism for controlling caching behavior:
Directive Meaning

max-age=3600 Cache is valid for 3600 seconds (1 hour)

no-cache Must revalidate with server before using cached copy
no-store Do NOT cache at all — sensitive data (e.g., bank transactions)
public Any cache (browser, CDN, proxy) can store this
private Only browser can cache — not CDN/proxy (e.g., user-specific data)
immutable Content will never change — skip revalidation entirely
s-maxage=3600 Like max-age, but only for shared caches (CDNs)

9.3 Cache Validation — ETags & Last-Modified

When a cache entry expires, the client can ask 'Has this changed?' instead of re-
downloading:
 • ETag approach:
○ Server sends: ETag: "v2-abc123"
○ Client sends: If-None-Match: "v2-abc123"
○ If unchanged: server replies 304 Not Modified (no body — saves bandwidth)
○ If changed: server replies 200 OK with new data and new ETag
• Last-Modified approach:
○ Server sends: Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT
○ Client sends: If-Modified-Since: Mon, 01 Jan 2024 00:00:00 GMT
○ Same outcome: 304 if unchanged, 200 if modified

Interview Tip: ETag is preferred over Last-Modified because timestamps can have 1-second
granularity issues and don't detect content-identical updates.

10. Authentication & Authorization in HTTP

Securing your API correctly is a core backend competency. Know all 3 main patterns.

10.1 Basic Authentication

• Credentials sent as Base64(username:password) in the Authorization header.
Authorization: Basic dXNlcjpwYXNzd29yZA==
• NEVER use over HTTP — only HTTPS. Base64 is encoding, NOT encryption.
• Used for simple internal APIs or machine-to-machine where simplicity > security.

10.2 Token-Based Auth (Bearer Tokens / JWT)

• Client logs in → Server generates a token → Client sends token in every request.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
• JWT (JSON Web Token) structure: [Link]
○ Header: algorithm & token type
○ Payload: claims (userId, role, expiry) — base64 encoded, NOT encrypted
○ Signature: ensures the token hasn't been tampered with
• Stateless — server doesn't store tokens. Scales horizontally easily.
• Always set expiry (exp claim). Use short-lived access tokens + refresh tokens.

Security Warning: JWT payload is only BASE64 encoded, not encrypted. NEVER put sensitive
data (passwords, SSN, etc.) in a JWT payload.

10.3 OAuth 2.0 (Authorization Framework)

• Used for third-party authorization: 'Login with Google / GitHub'
 • 4 grant types: Authorization Code (web apps), Implicit (deprecated), Client Credentials
(M2M), Device Flow (IoT)
• Returns Access Token (short-lived) + Refresh Token (long-lived) + optionally ID Token
(OIDC)
• OpenID Connect (OIDC) = OAuth 2.0 + identity layer for authentication

10.4 API Keys

• Simple static secret sent in header or query string: X-API-Key: abc123
• No expiry by default — must be rotated manually.
• Best for: server-to-server APIs, public APIs with rate limiting.

11. CORS — Cross-Origin Resource Sharing

CORS is a browser security mechanism that every backend engineer deals with. Understand it
conceptually and practically.

11.1 The Same-Origin Policy

• Browsers block web pages from making requests to a DIFFERENT origin than the one
that served the page.
• Same origin = same scheme + same host + same port.
○ [Link] can request [Link] — ALLOWED
○ [Link] can request [Link] — BLOCKED (different origin)

11.2 How CORS Works

• For simple requests (GET, POST with simple headers): browser adds Origin header.
Server must respond with Access-Control-Allow-Origin.
• For complex requests (PUT, DELETE, custom headers): browser sends a PREFLIGHT
(OPTIONS) request first.
○ OPTIONS /api/users → Access-Control-Allow-Origin, Access-Control-Allow-Methods
○ If server approves, browser then sends the actual request.

Key CORS Response Headers:

• Access-Control-Allow-Origin: * (any origin) or [Link] (specific origin)
• Access-Control-Allow-Methods: GET, POST, PUT, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization
• Access-Control-Max-Age: 86400 (cache preflight for 24 hours — reduces OPTIONS
requests)
• Access-Control-Allow-Credentials: true (required if sending cookies cross-origin)
 Common Bug: Access-Control-Allow-Origin: * does NOT work with credentials. You must specify
the exact origin when using cookies/auth headers cross-origin.

12. WebSockets — Real-Time Communication

HTTP is request-response. WebSockets enable full-duplex, real-time communication. Essential for
chat, live dashboards, gaming.

12.1 HTTP vs WebSocket

• HTTP: Client always initiates. Request → Response. Connection closes (or persists
briefly).
• WebSocket: After upgrade, BOTH client and server can send messages anytime. True
bidirectional.

12.2 WebSocket Handshake

WebSocket starts as HTTP and then upgrades:
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Server responds:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• After the 101 response, the HTTP connection is REPLACED by a WebSocket

connection.
• Data is sent as frames (binary or text) with very low overhead.
• Use WebSockets for: live chat, real-time notifications, collaborative editing, live sports
scores.
• Use SSE (Server-Sent Events) when you only need one-way server-to-client streaming.

Interview Tip: HTTP long-polling is an older alternative: client polls repeatedly. WebSockets are
more efficient as they eliminate constant reconnects.
13. HTTP Performance Optimization
Senior engineers must know how to design fast APIs. These topics appear frequently in system
design interviews.

13.1 Keep-Alive & Connection Pooling

• Reuse TCP connections instead of creating new ones per request.
• [Link]/Go HTTP clients support connection pooling natively.
• Set keep-alive timeouts appropriately (server should match load balancer settings).

13.2 Compression
• GZIP and Brotli compression reduce response body size by 60-80%.
• Client signals support via: Accept-Encoding: gzip, deflate, br
• Server compresses and responds with: Content-Encoding: gzip
• Brotli (br) is better than GZIP — 15-25% smaller — but older clients may not support it.

13.3 Content Delivery Networks (CDNs)

• CDNs cache static assets at edge servers geographically close to users.
• Reduces latency by serving from the nearest point of presence (PoP).
• CDNs also absorb DDoS attacks and handle TLS termination.
• Use Cache-Control: public, max-age=31536000, immutable for versioned static assets.

13.4 Pagination
• Never return unbounded lists — always paginate.
• Offset pagination: GET /users?page=2&limit=20 — simple but slow on large datasets
(DB scans all rows).
• Cursor pagination: GET /users?cursor=eyJpZCI6MTIzfQ&limit=20 — efficient, consistent
for real-time data.
• Include total count, next/prev links in response for discoverability.

14. Common Interview Questions & Answers

These are the most frequently asked HTTP questions in backend and system design interviews at
top tech companies.
Q1: What is the difference between HTTP and HTTPS?
Answer: HTTP transmits data in plain text. HTTPS adds TLS encryption, authentication via
certificates, and data integrity. All production systems must use HTTPS.

Q2: What is idempotency and why does it matter?

Answer: An operation is idempotent if calling it N times produces the same result as calling it
once. GET, PUT, DELETE are idempotent. POST is not. This matters for retry logic — you can
safely retry idempotent calls after network failures.

Q3: How would you design a rate limiting system?

Answer: Use a sliding window counter in Redis. Track requests per (user_id + time_window).
Return 429 Too Many Requests with Retry-After header when limit is exceeded. Consider
different limits per tier (free vs paid users).

Q4: How do you handle authentication in a microservices architecture?

Answer: Use JWT tokens issued by a central Auth Service. Each microservice validates the JWT
signature independently (stateless). Use a shared public key. Set short expiry (15 min) for access
tokens and refresh via refresh tokens.

Q5: Explain HTTP/2 multiplexing vs HTTP/1.1 pipelining.

Answer: HTTP/1.1 pipelining sends requests sequentially — if request 1 is slow, requests 2 and
3 are blocked (HOL). HTTP/2 multiplexing sends all requests as binary frames interleaved over
one connection — no blocking between independent streams.

Q6: When would you use WebSockets vs REST?

Answer: Use REST for standard CRUD operations with infrequent updates. Use WebSockets for
real-time bidirectional communication (chat, live collaborative tools, gaming). Use SSE for one-
way server-to-client streaming (notifications, live feeds).

Q7: How does CORS work and how do you fix a CORS error?
Answer: CORS is enforced by browsers. Server must include Access-Control-Allow-Origin in
responses. For complex requests, handle the OPTIONS preflight. Fix by adding correct CORS
headers — never just wildcard (*) when credentials are involved.

15. Quick Reference Cheat Sheet

Topic Remember This

DNS Flow Browser cache → OS cache → DNS resolver → Root NS → TLD NS

→ Authoritative NS
TCP Handshake SYN → SYN-ACK → ACK (3-way)
TLS Handshake ClientHello → ServerHello+Cert → KeyExchange → Session Keys →
Encrypted Data
Idempotent Methods GET, HEAD, PUT, DELETE, OPTIONS — safe to retry
Non-Idempotent POST, PATCH — retrying may create duplicates
401 vs 403 401 = Not authenticated | 403 = Authenticated but forbidden
Cache-Control no-store = never cache | no-cache = revalidate | max-age = TTL
ETag Fingerprint of resource, enables 304 Not Modified responses
JWT [Link] | Payload is base64 encoded, NOT
encrypted
CORS Preflight OPTIONS request sent before PUT/DELETE or custom headers
HTTP/1.1 vs 2 HTTP/2 = binary + multiplexing + header compression + no text HOL
HTTP/3 QUIC (UDP) + built-in TLS + no TCP HOL blocking
WebSocket HTTP Upgrade → 101 Switching Protocols → bidirectional frames
Rate Limiting 429 Too Many Requests + Retry-After header
REST Verbs GET=read, POST=create, PUT=replace, PATCH=partial,
DELETE=remove

Master these concepts and you'll stand out in any backend engineering interview!