HTTP & HTTPS
In one line
HTTP is the request-response language of the web (a method, a path, headers and a body in; a status code, headers and a body out), and HTTPS is the same HTTP sent inside an encrypted TLS connection.
What it is
HTTP (Hypertext Transfer Protocol) is an application-layer protocol where a client sends a request and a server sends back a response. A request has a method (GET, POST, PUT, PATCH, DELETE), a path, headers and an optional body. A response has a status code (200, 404, 500...), headers and an optional body.
HTTP is stateless: each request stands alone, and the server remembers nothing between requests unless the client sends something like a cookie or token. HTTPS is HTTP over TLS, usually on port 443 instead of 80, which encrypts the traffic, protects it from tampering and proves the server's identity with a certificate.
The protocol has evolved: HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many requests as streams over one TCP connection with compressed headers, and HTTP/3 runs over QUIC on UDP to avoid TCP head-of-line blocking.
Why interviewers ask
Almost every backend and frontend role touches HTTP daily. Interviewers check that you know methods and their safety and idempotency, status code classes, caching headers, cookies and why HTTPS is mandatory. It is also the base for questions like 'what happens when you type a URL' and API design discussions.
How it works
- 1The client resolves the host name with DNS and opens a TCP connection (or a QUIC connection for HTTP/3) to port 443.
- 2For HTTPS, a TLS handshake verifies the server certificate and agrees on encryption keys before any HTTP data is sent.
- 3The client sends a request line and headers, for example 'GET /users/42 HTTP/1.1', 'Host: api.example.com', 'Authorization: Bearer ...'. POST and PUT also send a body, often JSON.
- 4The server routes the request, does the work and replies with a status line, headers (Content-Type, Cache-Control, Set-Cookie) and a body.
- 5The connection is kept alive for further requests (HTTP/1.1 keep-alive, or many parallel streams in HTTP/2 and HTTP/3) so the handshake cost is paid once.
Worked example · Creating an order and retrying safely
- Client sends POST /orders with body {item: 7, qty: 2} and header Idempotency-Key: abc123.
- Server creates order 501 and replies 201 Created with header Location: /orders/501.
- The response is lost on a flaky mobile network, so the client retries the same POST with the same key.
- The server sees key abc123 was already used and returns the stored 201 response instead of creating a second order. POST is not idempotent by itself; the key makes the retry safe.
- Client then sends GET /orders/501 and gets 200 OK with Cache-Control: private, max-age=60, so the browser may reuse it for 60 seconds.
- Client sends GET /orders/999 and gets 404 Not Found; a request without a valid token would get 401 Unauthorized.
Picture it
HTTP is ordering at a counter with a standard form: you tick what you want (method and path), add notes (headers) and get back a receipt with a result code. HTTPS is doing the same through a sealed, tamper-proof tube to a clerk whose ID badge you checked first.
Key patterns
Safe and idempotent methods
When: Deciding which requests can be retried or cached
How: GET and HEAD are safe (no side effects). GET, PUT and DELETE are idempotent (repeating gives the same result). POST and PATCH are not idempotent by default; add an idempotency key.
Status code classes
When: Designing or debugging an API
How: 2xx success, 3xx redirect or not modified, 4xx client error (fix the request), 5xx server error (retry may help).
Conditional requests
When: Large or frequently fetched resources
How: Server sends ETag or Last-Modified; client sends If-None-Match or If-Modified-Since; server replies 304 with no body when unchanged.
State on a stateless protocol
When: Logins and sessions
How: Use a cookie holding a session id (marked HttpOnly, Secure, SameSite) or a bearer token in the Authorization header.
Real-world use
REST APIs
Stripe and GitHub expose REST APIs over HTTPS using methods for actions and status codes for outcomes; Stripe supports an Idempotency-Key header so payment retries never double-charge.
Browser caching
Sites serve static files with Cache-Control: max-age=31536000 and a hash in the file name, so browsers reuse them for a year and new deploys simply use new names.
HTTP/2 and HTTP/3
Google, Cloudflare and most large sites serve HTTP/2 and HTTP/3; one connection carries dozens of parallel requests for a page's assets instead of opening six TCP connections per host as HTTP/1.1 browsers did.
HTTPS everywhere
Let's Encrypt issues free certificates, and Chrome marks plain HTTP pages as 'Not secure', so nearly all web traffic is now HTTPS; HSTS headers tell browsers never to use plain HTTP for a domain.
In a project
You are designing the public API for a food delivery app used by mobile clients on unreliable networks.
- Model resources with clear URLs (/restaurants, /orders/{id}) and use GET for reads, POST to create, PATCH for partial updates and DELETE to cancel.
- Return precise status codes: 201 on create, 400 for bad input, 401 or 403 for auth problems, 404 for missing items, 409 for conflicts, 429 for rate limits, 5xx only for server faults.
- Require an Idempotency-Key on POST /orders so retries after timeouts never create duplicate orders.
- Serve menus with Cache-Control and ETag so clients revalidate cheaply and get 304 Not Modified when nothing changed.
- Force HTTPS with HSTS and use HTTP/2 so the app loads a screen's data over one connection.
Impact: Duplicate orders from retries drop to zero, menu traffic falls by around half thanks to 304 responses, and client developers can handle errors correctly from the status code alone.
Trade-offs
Use it when
- HTTP request-response: CRUD APIs, page loads, file downloads
- HTTP/2 or HTTP/3: pages with many small assets or APIs with many parallel calls
- HTTPS: always, for any traffic on the public internet
Avoid it when
- Plain HTTP request-response for server-initiated real-time updates; use WebSockets or Server-Sent Events
- Polling every second for changes that are rare; it wastes requests and battery
- Plain HTTP (no TLS) anywhere passwords, tokens or personal data travel
Cost: A new HTTPS connection over TCP with TLS 1.3 costs about 2 round trips before the first response bytes (1 for TCP, 1 for TLS); HTTP/3 with QUIC needs about 1, and 0 on resumption.
Common mistakes
- Saying HTTPS hides everything: it encrypts paths, headers and bodies, but the server IP and usually the host name (via DNS and the TLS SNI field) are still visible.
- Calling POST idempotent or PUT non-idempotent.
- Returning 200 with an error message in the body instead of a proper 4xx or 5xx code.
- Confusing 401 (not authenticated, who are you?) with 403 (authenticated but not allowed).
- Thinking HTTP/2 fixes all head-of-line blocking: it removes it at the HTTP layer, but a lost TCP packet still stalls every stream; HTTP/3 fixes that.
Interview questions
Quick revision
- Request: method, path, headers, body. Response: status, headers, body.
- Safe: GET, HEAD. Idempotent: GET, HEAD, PUT, DELETE. Not idempotent: POST, PATCH.
- 2xx ok, 3xx redirect, 4xx client error, 5xx server error.
- 200 OK, 201 Created, 204 No Content, 301/302 redirect, 304 Not Modified, 400, 401, 403, 404, 409, 429, 500, 502, 503.
- HTTPS = HTTP over TLS, port 443; HTTP default port 80.
- HTTP/1.1 keep-alive; HTTP/2 multiplexing over TCP; HTTP/3 over QUIC (UDP).
- Cache-Control, ETag and 304 save bandwidth; cookies flagged HttpOnly, Secure, SameSite.
Check yourself
1. Which HTTP method is idempotent?
2. A logged-in user requests an admin page they are not allowed to see. Which status is most correct?
3. What does HTTPS add on top of HTTP?
4. A client sends If-None-Match with an ETag that still matches. What should the server return?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.