jd five

HTTP Semantics

Learning goals

Read and write HTTP/1.1-style messages confidently: request line, headers, body; know what safe and idempotent mean for methods; interpret status code classes; and connect semantics to real API design—not just “GET for read, POST for write.”

HTTP in one sentence

HTTP is a text-based (conceptually) request/response protocol: the client sends a method, a target (path + query), and headers; the server returns a status code, headers, and often a body. It is stateless—each request carries what the server needs; session state is added via cookies, tokens, or server-side stores.

After chapter 2 you have seen this ride on TLS over TCP. Here we focus on meaning: what verbs imply, what status codes promise, and what shape messages take.

Request and response shape

Request:

GET /networking/learn/foundations/dns/ HTTP/1.1
Host: learning.jdfive.com
Accept: text/html
User-Agent: curl/8.0

Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234

<!DOCTYPE html>...

Parts:

  • Start line — method + path + version, or version + status + reason phrase.
  • Headers — key/value metadata (case-insensitive names in HTTP/1.1).
  • Blank line — separates headers from body.
  • Body — optional; common on POST/PUT/PATCH responses and many error payloads.

HTTP/2 and HTTP/3 compress and frame this differently on the wire, but browsers and servers still expose the same semantic model to your application code.

Methods (verbs)

Method Typical use Safe? Idempotent?
GET Fetch representation Yes Yes
HEAD Like GET, no body Yes Yes
POST Create, action, non-idempotent ops No No
PUT Replace resource at URL No Yes
PATCH Partial update No Often*
DELETE Remove resource No Yes
OPTIONS Capabilities / CORS preflight Yes Yes

*PATCH idempotency depends on patch document design—do not assume blindly.

Safe = should not change server state (still might hit logs or rate limits). Idempotent = repeating the same request has the same effect as once (GET, PUT, DELETE—not POST).

Plain English: retry a idempotent request after a timeout if you are unsure it landed; be careful retrying POST (might double-charge or duplicate rows).

Status code classes

First digit tells the class:

Class Range Meaning
1xx 100–199 Informational (rare in app code)
2xx 200–299 Success — 200 OK, 201 Created, 204 No Content
3xx 300–399 Redirection — 301 Moved Permanently, 302 Found, 304 Not Modified
4xx 400–499 Client error — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests
5xx 500–599 Server error — 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

Memorable distinctions:

  • 401 — authentication required or failed (who are you?).
  • 403 — authenticated but not allowed (you may not do this).
  • 404 — no resource at this URL (or hidden as 404 for privacy).
  • 502/504 — proxy/gateway upstream problem, not always your app process.

Examples in API design

Good GET:

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

Create with POST:

POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"item_id": 7, "qty": 2}

Response might be 201 Created with Location: /api/orders/991 header pointing at the new resource.

Idempotent replace:

PUT /api/users/42/profile HTTP/1.1
Content-Type: application/json

{"display_name": "Ada"}

Sending the same PUT again should leave profile in the same state, not create a second profile.

Version, connection, and statelessness

  • HTTP/1.1 defaults to persistent connections (Connection: keep-alive)—multiple requests on one TCP connection.
  • Stateless does not mean “no logged-in users”; it means the protocol does not define server memory of past requests. Cookies, Authorization headers, and URL tokens carry continuity.

Common mistakes (beginners)

  1. Using GET for actions that change data — crawlers, prefetch, and caches may trigger GET unintentionally; use POST/PUT/PATCH/DELETE appropriately.
  2. Treating all 5xx as “our bug.” — 502 often means load balancer could not reach a healthy upstream; 503 may be deliberate overload protection.
  3. Ignoring 204 vs 200 with empty body — clients should handle 204 No Content without expecting a body.
  4. POST for everything — works in small apps but hurts cacheability, semantics, and HTTP-aware tooling.
  5. Assuming reason phrases matter — HTTP/1.1 404 Not Found; clients should rely on the numeric code, not the text phrase.

Practice checkpoint

  1. Which methods are safe and idempotent?

    • Answer: GET and HEAD are safe and idempotent; OPTIONS too. PUT and DELETE are idempotent but not safe. POST is neither.

  2. 401 vs 403 in one line each?

    • Answer: 401 = authentication missing/invalid; 403 = authenticated (or anonymous policy) but access denied.

  3. Why might retrying a POST payment request be dangerous?

    • Answer: POST is not idempotent; a retry may process the payment twice unless you use idempotency keys or deduplication.

  4. Name the three parts of an HTTP response after the connection exists.

    • Answer: Status line, headers, optional body (separated by blank line after headers).

Interview angles

  • “Is HTTP stateless?” — Yes at the protocol level; applications add state via cookies, sessions, JWTs.
  • “Idempotent methods?” — GET, HEAD, PUT, DELETE, OPTIONS; POST is the classic non-idempotent case.
  • “Difference between 301 and 302?” — Both redirect; 301 implies permanent (SEO/link aggregators may update); 302 temporary. Real clients and caches treat them with nuance—know your CDN behavior.

Next: /networking/learn/http/headers-cookies-caching/