Phase 1 — Foundations lesson-0002

HTTP Deep Dive

The language your server speaks. Every request and response follows this exact format.

Anatomy of an HTTP Request

Every HTTP request has the same four-part structure:

POST /api/users HTTP/1.1            ← Request line: METHOD path version
Host: api.example.com               ← Headers (key: value pairs)
Content-Type: application/json
Authorization: Bearer eyJhbGc...
                                     ← Blank line separates headers from body
{                                    ← Body (only for POST/PUT/PATCH)
  "name": "Alice",
  "email": "alice@example.com"
}

Anatomy of an HTTP Response

HTTP/1.1 201 Created               ← Status line: version code message
Content-Type: application/json      ← Response headers
Location: /api/users/42
                                     ← Blank line
{                                    ← Response body
  "id": 42,
  "name": "Alice"
}

HTTP Methods

Methods tell the server what action to perform. Use the right one — it signals intent to every developer who reads your API.

GET

Read a resource. Never modify data. Safe & idempotent.

POST

Create a new resource. Not idempotent — sends twice = two records.

PUT

Replace a resource entirely. Idempotent — same result every time.

PATCH

Partially update a resource. Only send fields that change.

DELETE

Remove a resource. Idempotent — deleting twice = still deleted.

Idempotency

An operation is idempotent if calling it multiple times produces the same result as calling it once. GET, PUT, DELETE are idempotent. POST is not — that's why submitting a form twice can create two orders.

Status Codes

The three-digit code is the first thing you check in any response. They're grouped by their first digit:

200OKRequest succeeded. Body contains the result.

201CreatedResource created (use after POST). Include Location header.

204No ContentSuccess but no body (common for DELETE).

301Moved PermanentlyResource has a new URL forever. Clients should update bookmarks.

304Not ModifiedCached version is still valid — skip re-downloading.

400Bad RequestClient sent malformed data. Fix your request.

401UnauthorizedNot authenticated — you need to log in first.

403ForbiddenAuthenticated, but you don't have permission.

404Not FoundResource doesn't exist at this URL.

422Unprocessable EntitySyntax valid but semantics fail (e.g. invalid email format).

429Too Many RequestsRate limited. Retry after some time.

500Internal Server ErrorSomething broke on the server. Not the client's fault.

503Service UnavailableServer is overloaded or down for maintenance.

Common Mistake

Never return 200 OK with an error message in the body. Use the correct 4xx/5xx code. Clients (and monitoring tools) check the status code first.

Important Headers

Header	Direction	Purpose
`Content-Type`	Both	Format of the body (`application/json`, `multipart/form-data`…)
`Authorization`	Request	Credentials — typically `Bearer <token>`
`Accept`	Request	What format the client wants back
`Location`	Response	URL of newly created resource (with 201)
`Cache-Control`	Both	Caching instructions for browsers and proxies
`X-Request-ID`	Both	Unique ID for tracing a request through logs

HTTP/1.1 vs HTTP/2 vs HTTP/3

You don't need to configure these — your platform handles it. But knowing the difference helps you understand performance:

HTTP/1.1 — One request per TCP connection at a time. Workarounds (connection pooling, bundling) needed for speed.
HTTP/2 — Multiplexing: many requests over one connection simultaneously. Binary protocol. Used by ~65% of the web.
HTTP/3 — Built on UDP (QUIC). Even faster connection setup. Handles packet loss better. Still rolling out.

🧠 Check Your Understanding

Go Deeper

Primary source: MDN — HTTP request methods

Reference: httpstatuses.com — bookmark this, you'll use it weekly.

Ask your teacher: "When should I use PUT vs PATCH?" or "What's the difference between 401 and 403?"

← Lesson 1 Next: What is Node.js? →