HTTP and HTTPS

Why it matters

HTTP is the protocol your system speaks to the outside world and, increasingly, to itself. Its methods encode intent, its status codes encode outcomes, and its headers carry caching, authentication, content negotiation and tracing. A surprising number of design decisions (what is cacheable, what is safe to retry, how a client knows it was rate limited) are HTTP decisions. Knowing the protocol well makes APIs cheaper to build and easier to operate.

The idea

HTTP is a stateless request-response protocol: the client sends a request (method, path, headers, optional body), the server returns a response (status code, headers, optional body), and nothing about one exchange is remembered for the next unless the application adds it (cookies, tokens).

Methods carry semantics

Method	Meaning	Safe	Idempotent	Design implication
GET	Read a resource	Yes	Yes	Cacheable; retry freely; never change state
HEAD	GET without the body	Yes	Yes	Check existence or freshness cheaply
PUT	Replace a resource	No	Yes	Safe to retry; full representation
DELETE	Remove a resource	No	Yes	Safe to retry; second call returns 404 or 204
PATCH	Partial update	No	Not by default	Make it idempotent yourself or avoid retries
POST	Create or act	No	No	Needs an idempotency key to be retried safely

Status codes are an API

The first digit is the class: 2xx success, 3xx redirection, 4xx the client did something wrong, 5xx the server failed. A handful carry design weight. 201 Created with a Location header for new resources. 204 No Content for successful deletes. 304 Not Modified for a validated cache. 400 for malformed input versus 422 for well-formed but invalid. 401 not authenticated versus 403 authenticated but not allowed. 404 versus 410 Gone. 409 Conflict for version mismatches. 429 Too Many Requests with a Retry-After header for rate limits. 503 with Retry-After for overload, so clients back off instead of hammering.

Headers that carry decisions

Cache-Control, ETag and Last-Modified govern caching at the browser and at the CDN. Content-Type and Accept negotiate formats. Authorization carries tokens. Idempotency-Key makes POST retryable. Trace headers (traceparent) tie a request together across services. Correct headers are how one service tells the next what it may cache, retry and trust.

HTTPS: TLS underneath

HTTPS is HTTP over TLS. TLS gives three things: encryption (nobody on the path reads the bytes), integrity (nobody alters them) and authentication of the server through a certificate chain rooted in a trusted authority. The cost is a handshake, one round trip in TLS 1.3, and CPU for encryption, both small on modern hardware. Terminate TLS at the load balancer or edge so certificates live in one place, and re-encrypt to backends when the network between them is not fully trusted.

Versions

HTTP/1.1 sends one request at a time per connection, so browsers open six connections per host and still queue. HTTP/2 multiplexes many requests over one TCP connection with header compression, which removes the queueing at the HTTP layer but keeps TCP's head-of-line blocking underneath. HTTP/3 moves to QUIC over UDP: per-stream loss recovery, faster handshakes, and connection migration when a phone changes networks. Edge providers serve all three; your backend usually speaks HTTP/1.1 or HTTP/2 behind them.

Trade-offs

Statelessness makes HTTP easy to scale and cache but pushes session state into tokens and stores. Rich semantics (methods, codes, headers) make APIs self-describing but only if teams use them properly; returning 200 with an error body throws most of the protocol's value away. TLS everywhere is now a baseline, not a trade-off; where it is terminated is the design decision.

In an interview

Show the protocol doing work for you: "GETs are cacheable at the CDN with a 60-second max-age and an ETag for revalidation. Order creation is a POST with an idempotency key so client retries are safe. Rate limits return 429 with Retry-After so clients back off." Mention TLS termination at the balancer and HTTP/2 between edge and services. That is three design decisions expressed in protocol terms, which is how experienced engineers talk.