HTTP & HTTPS

HTTP is the contract at the system boundary#

GET /users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

The method communicates intent, the target identifies a resource, headers carry metadata, and an optional body carries a representation. The response combines a status code, headers, and optional content. That contract can stay stable while the backend architecture changes.

Methods and status behavior#

Use status codes to describe outcomes consistently: 200 success, 201 created, 202 accepted for later processing, 400 invalid input, 401 unauthenticated, 403 not permitted, 404 missing, 409 conflict, 429 limited, 500 unexpected failure, and 503 temporarily unavailable.

Stateless does not mean the application has no state#

HTTP semantics let a request be understood in isolation. Applications still maintain identity and workflow using cookies, session identifiers, tokens, databases, and caches. Avoid making an in-memory server session the only copy unless routing and failure behavior explicitly support it.

Connections, HTTP/2, and HTTP/3#

Persistent connections amortize setup across requests. HTTP/2 multiplexes multiple logical request streams over a connection. HTTP/3 carries HTTP semantics over QUIC, a secure multiplexed transport over UDP. Implementation detail is usually a follow-up, not the starting point for a product architecture.

HTTPS adds TLS: the client validates server identity from certificates, negotiates protected communication, and pays some connection setup cost. Reuse and session mechanisms reduce repeated setup. Candidates should explain what TLS provides, not implement its cryptography.