HTTP Protocol - ggcoder.com

HTTP Methods

HTTP methods define the intent of a request. The key properties are safety (no side effects) and idempotency (repeating the request produces the same result). REST APIs rely on these semantics for predictable behaviour.

GET

Retrieve a resource. Safe and idempotent — no side effects, repeating it changes nothing.

POST

Create a new resource or trigger an action. Not idempotent — repeated calls may create duplicates.

PUT

Replace a resource entirely. Idempotent — sending the same request twice yields the same result.

PATCH

Partially update a resource. Only the provided fields are changed, the rest remain untouched.

DELETE

Remove a resource. Idempotent — deleting an already-deleted resource should return 404 or 204.

HEAD / OPTIONS

HEAD fetches only headers (no body). OPTIONS lists allowed methods, used in CORS preflight.

HTTP Methods

Standard methods defined by RFC 7231

Status Code Groups

1xx through 5xx grouped by purpose

Multiplexed

HTTP/2

Multiple streams over one TCP connection

QUIC

HTTP/3

UDP-based transport, 0-RTT reconnects

✓Idempotency matters for retries

When a network error occurs, clients can safely retry GET, PUT, and DELETE. Retrying POST without deduplication can create duplicate records — use idempotency keys for critical write operations.

Status Codes

Status codes are grouped by their first digit. A well-designed API returns the most specific code available, not just 200 for everything or 500for client mistakes.

2xx — Success

200 OK — general success, body contains result

201 Created — resource created, Location header points to it

204 No Content — success with no response body (DELETE, PUT)

3xx — Redirection

301 Moved Permanently — update bookmarks, SEO weight transfers

302 Found — temporary redirect, keep original method

304 Not Modified — cached response is still fresh

4xx — Client Error

400 Bad Request — malformed syntax or invalid parameters

401 Unauthorized — not authenticated (send credentials)

403 Forbidden — authenticated but not authorized

404 Not Found — resource does not exist

422 Unprocessable Entity — validation failed

429 Too Many Requests — rate limit exceeded

5xx — Server Error

500 Internal Server Error — unhandled exception on the server

502 Bad Gateway — upstream server returned invalid response

503 Service Unavailable — server overloaded or in maintenance

504 Gateway Timeout — upstream did not respond in time

Headers

Headers carry metadata about the request or response. They control content negotiation, authentication, caching, and CORS. Keep custom headers prefixed with X-(deprecated by RFC 6648) or use a vendor namespace like My-App-Request-Id.

Request Headers	Response Headers
Authorization: Bearer <token>	WWW-Authenticate: Bearer realm=...
Accept: application/json	Content-Type: application/json
Content-Type: application/json	Cache-Control: max-age=3600
If-None-Match: "etag-value"	ETag: "etag-value"
Origin: https://example.com	Access-Control-Allow-Origin: *
Accept-Encoding: gzip, br	Content-Encoding: gzip

Caching

HTTP caching eliminates redundant network round-trips. The browser checks its cache before sending a request; if valid, it serves the cached copy. The server controls cache behaviour through Cache-Control and ETag headers.

Request

→

Cache check

→

Fresh?

→

Serve cached

→

Revalidate

Cache-Control directives

# Cache-Control directives

# Public CDN cache for 1 day, stale-while-revalidate for 1 hour
Cache-Control: public, max-age=86400, stale-while-revalidate=3600

# Private (browser only), no CDN caching
Cache-Control: private, max-age=3600

# Never cache (auth pages, real-time data)
Cache-Control: no-store

# Cached but must revalidate every request
Cache-Control: no-cache

# Conditional request headers (sent by browser)
If-None-Match: "abc123"          # ETag from previous response
If-Modified-Since: Thu, 01 Jan 2026 00:00:00 GMT

iETag vs Last-Modified

ETags are content hashes — more precise than timestamps. When the browser sendsIf-None-Match with a cached ETag, the server returns 304 Not Modifiedinstead of re-sending the full body, saving bandwidth.

HTTP/2 vs HTTP/3

HTTP/2 introduced multiplexing over a single TCP connection, eliminating head-of-line blocking at the HTTP layer. HTTP/3 replaces TCP with QUIC (UDP-based), solving transport-level head-of-line blocking and improving performance on lossy connections.

HTTP Request Lifecycle

DNS Resolve

Translate the domain name to an IP address

TCP Connect

3-way handshake to establish the connection

TLS Handshake

Negotiate encryption for HTTPS connections

Send Request

Client sends HTTP request with headers and body

Receive Response

Server returns status code, headers and body

Render

Browser processes and displays the content

HTTP/2	HTTP/3
Transport: TCP + TLS	Transport: QUIC (UDP-based)
Multiplexed streams over one connection	Independent QUIC streams, no TCP HoL blocking
Header compression: HPACK	Header compression: QPACK
Connection setup: 1–2 RTT	0-RTT reconnects for returning clients
~97% browser support	~95% browser support (still growing)

✓Adoption in practice

Most modern CDNs (Cloudflare, Fastly, AWS CloudFront) negotiate HTTP/3 automatically via the Alt-Svc header. You typically get HTTP/3 for free by using a CDN — no application code changes needed.