Overview
HTTP (Hypertext Transfer Protocol) is the request-response protocol of the web. A client sends a method (GET, POST, PUT, DELETE), a path, headers, and an optional body; the server replies with a status code, headers, and a body. HTTP is stateless: each request carries everything the server needs, which is why cookies and tokens exist.
HTTPS is HTTP over TLS. TLS encrypts the traffic, proves the server's identity with a certificate signed by a trusted authority, and detects tampering. Today HTTPS is mandatory for any production system: browsers flag HTTP as insecure, and features like HTTP/2, service workers, and geolocation require it.
HTTP is filling out a standard form: what you want (method and path), extra details (headers), and attachments (body). The clerk returns a stamped result code. HTTPS puts that form in a tamper-proof envelope that only the verified office can open.
When to use it
- Any web or API communication between clients and servers.
- Designing REST APIs: choosing methods, status codes, and headers.
- Caching decisions with Cache-Control, ETag, and Last-Modified.
- Security: protecting credentials and data in transit.
Where it shows up in interviews
Recognize it when: choose methods, status codes, idempotency, and caching headers.
- Design a REST API for an e-commerce cart
- Design a public API
Recognize it when: reduce load and latency for read-heavy content.
- Design a news site
- Design a CDN-backed image service
Recognize it when: where to decrypt traffic in your architecture.
- Design the edge of a web platform
- Design a secure internal service mesh
Where it is used in real software
A free certificate authority that issues automated 90-day certificates; it moved the web from under 50% HTTPS to over 90%.
AWS ALB, Nginx, and Cloudflare decrypt traffic at the edge and forward it to backends, often re-encrypted.
Sites like Google and banks are hardcoded in browsers to always use HTTPS, preventing downgrade attacks.
Key terms
- Method
- GET (read), POST (create / action), PUT (replace), PATCH (partial update), DELETE (remove).
- Status code
- 2xx success, 3xx redirect, 4xx client error, 5xx server error.
- Idempotent
- Repeating the request has the same effect as doing it once (GET, PUT, DELETE).
- Cache-Control
- Header that tells browsers and CDNs whether and how long to cache.
- TLS certificate
- Proves a server owns a domain; signed by a certificate authority.
TLS 1.3 handshake
- 1ClientHello
The client sends supported cipher suites and a key share (its half of a Diffie-Hellman exchange).
- 2ServerHello and certificate
The server picks a cipher, sends its key share, its certificate chain, and a signature proving it holds the private key.
- 3Client verifies
The client checks the certificate chain up to a trusted root, the domain name, and the expiry date.
- 4Both derive session keys
From the key shares, both sides compute the same symmetric keys without sending them.
- 5Encrypted HTTP
All HTTP traffic is now encrypted with fast symmetric crypto (AES-GCM or ChaCha20). One round trip total.
STEP 1A TCP connection is established first (1 RTT).
Status codes you must know
Pick the most specific correct code; clients and monitoring depend on it
| Code | Meaning | Typical use |
|---|---|---|
| 200 / 201 / 204 | OK / Created / No Content | Successful read, create, or delete |
| 301 / 302 / 304 | Moved / Found / Not Modified | Permanent redirect, temporary redirect, cache revalidation |
| 400 / 401 / 403 | Bad Request / Unauthorized / Forbidden | Invalid input, missing auth, not allowed |
| 404 / 409 / 429 | Not Found / Conflict / Too Many Requests | Missing resource, version conflict, rate limited |
| 500 / 502 / 503 / 504 | Server error / Bad Gateway / Unavailable / Gateway Timeout | Bug, upstream failure, overload, upstream too slow |
NOWCode: 200 / 201 / 204 | Meaning: OK / Created / No Content | Typical use: Successful read, create, or delete
401 means 'who are you?' (not authenticated); 403 means 'I know who you are, but no' (not authorized). 502 and 504 usually come from a proxy describing a problem with the server behind it.
Implementation
GET /api/products/42 HTTP/1.1Host: shop.example.comAccept: application/jsonAuthorization: Bearer eyJhbGciOi...If-None-Match: "v7" HTTP/1.1 304 Not ModifiedETag: "v7"Cache-Control: private, max-age=60 POST /api/orders HTTP/1.1Host: shop.example.comContent-Type: application/jsonIdempotency-Key: 8f14e45f-ea3c-4c8b {"productId": 42, "quantity": 2} HTTP/1.1 201 CreatedLocation: /api/orders/9001Complexity and performance
TLS 1.2 needed 2 RTT.
Session tickets / 0-RTT data.
AES-GCM is hardware accelerated on modern CPUs.
Trade-offs
Terminating at the load balancer simplifies certificates and lets it inspect traffic; re-encrypting to backends (or mTLS) is needed for zero-trust and compliance.
PUT replaces the whole resource and is idempotent; PATCH sends only changes, saving bandwidth but requiring careful semantics.
Variants and related techniques
Both client and server present certificates; common for service-to-service authentication.
Multiplexing and faster handshakes; see HTTP/1.1 to HTTP/3.
ETag and If-None-Match let clients revalidate cached data and receive 304 without a body.
Common mistakes
- Using GET for actions that change data.
Fix: GET must be safe; crawlers and prefetchers will call it. Use POST, PUT, PATCH, or DELETE.
- Returning 200 with an error message in the body.
Fix: Use proper 4xx/5xx codes so clients, retries, and monitoring behave correctly.
- Letting certificates expire.
Fix: Automate renewal (ACME / cert-manager) and alert well before expiry.
Interview questions
What does HTTPS protect against, and what does it not?
It protects confidentiality, integrity, and server identity against network attackers. It does not protect against a compromised server, malicious clients, or application bugs like SQL injection.
Which HTTP methods are idempotent and why does it matter?
GET, HEAD, PUT, DELETE, and OPTIONS are idempotent. Clients, proxies, and load balancers can safely retry them after a timeout; POST retries need an idempotency key to avoid duplicates.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Inspect headers of a real site with curl -I | Easy | Caching and security headers. |
| Design status codes and headers for an orders API | Medium | Semantics and idempotency. |
| Design TLS termination for a multi-tenant SaaS | Hard | Certificates at scale. |