nonobie — Real dev skills, explained like a friend would

What you'll learn

By the end of this chapter you will:

Read and write any HTTP request by hand
Memorize the meaningful status codes
Know which headers are safe, which are dangerous
Understand what TLS gives you and what it does not

The why

HTTP is the only language the web speaks. If you know it cold, you read docs once and write code that works. If you don't, you'll spend your career chasing mystery bugs that turn out to be a missing header.

💡HTTP is a polite letter

An HTTP request is a politely formatted text message. It has a method (what you want), a path (where), some headers (metadata), and an optional body (the payload).

http

POST /orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...
 
{"itemId": "sku_42", "quantity": 2}

You can type that by hand into telnet on port 80 and a webserver will respond. The whole web is built on this format.

HTTP methods (verbs)

Every HTTP request starts with a method. Each method has a precise meaning. Pick the wrong one and you violate rules, rules, and a hundred years of tradition.

Method	Use for	Safe?	?
`GET`	Read a resource	✅	✅
`POST`	Create a new resource (or non-idempotent action)	❌	❌
`PUT`	Replace a resource entirely	❌	✅
`PATCH`	Modify part of a resource	❌	✅ (should be)
`DELETE`	Delete a resource	❌	✅
`HEAD`	GET, but only headers (no body)	✅	✅
`OPTIONS`	Ask "what can I do here?" — used by CORS	✅	✅

Safe = doesn't change server . GET should be safe; if your GET deletes data, you have a bug.
Idempotent = doing it twice is the same as doing it once. PUT, DELETE are idempotent; POST is usually not.

The most common newbie mistake

Using GET to delete or create resources. Browsers, crawlers, link-previewers, and CDNs all happily call GET URLs unsolicited. If a GET /api/users/42/delete exists, Google Bot will delete user 42.

Status codes you actually need to know

There are 60+ HTTP status codes. You need 15.

2xx — Success

200 OK — generic success, body usually included
201 Created — resource created (POST)
204 No Content — success, no body (DELETE, PATCH)

3xx — Redirect

301 Moved Permanently — cached forever by browsers (dangerous!)
302 Found — temporary redirect
304 Not Modified — cache is still valid

4xx — Client error

400 Bad Request — malformed
401 Unauthorized — missing or invalid auth (badly named — should be "Unauthenticated")
403 Forbidden — authenticated but not allowed
404 Not Found — resource doesn't exist (or you don't want to admit it does)
409 Conflict — request conflicts with current state (duplicate email, version mismatch)
422 Unprocessable Entity — well-formed but semantically invalid (failed )
429 Too Many Requests — rate-limited

5xx — Server error

500 Internal Server Error — your code threw, nothing more specific to say
502 Bad Gateway — your upstream (DB, third-party API) failed
503 Service Unavailable — overloaded or maintenance
504 Gateway Timeout — upstream took too long

401 vs 403

401 means "we don't know who you are." 403 means "we know who you are, and you can't." Mixing them up causes auth bugs no one can debug.

Headers — the metadata layer

Headers are key-value pairs that say how to interpret the request or response. There are dozens. Here are the ones you'll meet daily:

Request headers

Host — which virtual host on the server
Authorization — credentials (Bearer <token> or Basic <base64>)
Content-Type — the body's format (application/json, multipart/form-data)
Accept — what formats the client can read back
User-Agent — what client is calling (browser, curl, your service)
Cookie — session/auth cookies
X-Forwarded-For — added by proxies; the original client IP

Response headers

Content-Type — format of the body
Content-Length — size in bytes
Set-Cookie — server tells the browser to remember a value
Cache-Control — caching rules (no-store, max-age=3600, public)
Location — where to redirect (used with 3xx)
Strict-Transport-Security — "always use HTTPS for this domain"
Content-Security-Policy — frontend XSS defense

Custom headers

Anything you invent — convention is to prefix with X- (legacy) or just your-name-. Examples: X-Request-Id, Stripe-Signature.

Cookies vs Authorization headers

Two ways to send credentials with every request:

Cookies. Set by the server with Set-Cookie. Browser auto-attaches them to every request to that domain. Good: invisible to JS if HttpOnly. Bad: subject to CSRF unless you set SameSite.

Authorization header. Client must read the token from somewhere and add Authorization: Bearer ... to each request. Good: no CSRF (the browser doesn't auto-send it). Bad: easier to leak if the client stores it in localStorage.

For browser-based apps, HttpOnly cookies are usually the safer choice. For mobile apps and server-to-server, tokens are simpler.

HTTPS / TLS — what it actually buys you

HTTPS = HTTP wrapped in TLS. TLS does three things:

Encrypts the body and headers. An eavesdropper sees a meaningless blob.
Authenticates the server. The server presents a certificate signed by a CA. Your browser verifies the chain before sending data.
Detects tampering. Any change to the bytes in flight breaks the integrity check.

What TLS does not do:

It does not hide the destination IP (your ISP still sees where you connected).
It does not hide the hostname (SNI is sent unencrypted unless you have ECH, which is still rolling out).
It does not make your app secure. injection, broken auth, XSS — all unaffected.

Inspect a real TLS handshake

bash

$ curl -v https://example.com 2>&1 | grep -E "TLS|subject:"
* TLSv1.3 (IN), TLS handshake, Server hello
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions
* TLSv1.3 (IN), TLS handshake, Certificate
*  subject: CN=example.com
* TLSv1.3 (IN), TLS handshake, CERT verify

HTTP/1.1 vs HTTP/2 vs HTTP/3

You should know what each is and when to care.

HTTP/1.1 (1997). Text-based. One request per TCP connection (mostly). Many connections in parallel.
HTTP/2 (2015). Binary. Multiplexes many requests over one TCP connection. Solves "head-of-line blocking" at the HTTP layer but not TCP.
HTTP/3 (2022). Same semantics, but runs over QUIC (which runs over UDP). Solves head-of-line blocking at the transport layer too. Faster on lossy networks.

Practical impact for backend devs: usually you write code the same way for all three. Your reverse proxy (nginx, Cloudflare) handles the wire format and translates.

Common mistakes

Mistake	Why it's wrong	What to do
Returning 200 with `{"error": "..."}`	Frontends, monitoring, and retries all key off the status code	Return the actual HTTP error code (4xx/5xx)
Using POST for everything	No caching, no idempotency guarantees	Use GET for reads, the right verb for writes
`Authorization: <token>` without `Bearer` prefix	Many servers strip the scheme; yours might not	Always include `Bearer`
Putting JWTs in URL query strings	Logged everywhere, leaks in referrers	Use Authorization header
Caching POST responses	They're never cached, even by you	Use GET for cacheable reads

Production · Performance · Security notes

Production. Use 429 correctly with Retry-After headers. Use 503 with Retry-After during deploys. Clients that respect these will not retry-storm you.

Performance. Enable HTTP/2 at your reverse proxy. Set Cache-Control headers thoughtfully — public, max-age=31536000, immutable for fingerprinted assets, no-store for personalized data.

Security. Always set Strict-Transport-Security. Never accept HTTP for anything that matters. Don't log Authorization headers (a depressing number of services do).

Exercises

Beginner. Use curl -v to make a GET to https://httpbin.org/get. Read every line of the verbose output.
Beginner. Use curl to send a POST with a JSON body to https://httpbin.org/post. Check the echoed headers and json fields.
Intermediate. Make the same request twice with curl -I (HEAD). Compare to a full GET.
Intermediate. Use openssl s_client -connect example.com:443 to see the raw TLS handshake.
Advanced. Set up a local nginx that serves both HTTP/1.1 and HTTP/2. Use curl --http1.1 and curl --http2 and compare the protocol negotiation.

Interview questions

Beginner. What's the difference between 401 and 403? 401 = not authenticated. 403 = authenticated but not allowed.

Senior. When would you choose cookies over Authorization headers? When the client is a browser and you want HttpOnly, SameSite protection. Tokens make more sense for mobile or service-to-service.

Senior. Walk me through what happens when you hit a 502. The reverse proxy got an error from your origin. Could be: origin down, origin returned malformed HTTP, origin timed out, TLS handshake to origin failed. Knowing which one matters.

Summary

HTTP is a text protocol with methods, headers, status codes, and a body. Each piece has a precise meaning. HTTPS adds encryption, server authentication, and tamper detection — but does not make your app secure. Pick the right method, return the right status code, and respect the verbs and you'll write APIs that play well with every tool in existence.

Quick recall

GET — read, safe, idempotent, cacheable.
POST — create / non-idempotent action.
PUT/PATCH — update.
DELETE — remove.
2xx success · 3xx redirect · 4xx client error · 5xx server error.
TLS encrypts + authenticates + detects tampering. It does not secure your app logic.

Quiz

Which HTTP methods are idempotent?
What does status 201 mean?
What's the difference between Content-Type and Accept?
Why is HttpOnly important on cookies?
Name two things TLS does NOT protect against.

Chapter 3 — HTTP & HTTPS Deep Dive