HTTP, HTTPS & TLS Basics
You'll learn to
- -Describe what HTTP is and why it is stateless
- -Explain what TLS adds on top of HTTP
- -Recognize the most important HTTP status code families
Once a client knows a server's address (via DNS), it needs a shared language to actually ask for something. That language, for almost everything on the web, is HTTP (HyperText Transfer Protocol). HTTP defines a request (a method like GET or POST, a path, headers, and optionally a body) and a response (a status code, headers, and a body).
HTTP Is Stateless
Each HTTP request is independent: the server does not automatically remember anything about the client's previous requests. This is a deliberate design choice, and it is one of the most important ideas in this entire course: statelessness is what makes horizontal scaling possible (Module 2). If a server remembered nothing about you between requests, any server could handle any of your requests, and you could add more servers freely. The catch is that real applications do need state (logged-in sessions, shopping carts), so that state has to live somewhere else (a cookie, a token, or a shared store like Redis), not on the server that happened to answer last time.
Status Codes at a Glance
- -2xx: Success (200 OK, 201 Created)
- -3xx: Redirection (301 Moved Permanently, 304 Not Modified)
- -4xx: Client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests)
- -5xx: Server error (500 Internal Server Error, 503 Service Unavailable)
HTTPS and TLS
Plain HTTP travels as readable text: anyone on the network path can read or tamper with it. TLS (Transport Layer Security) wraps the connection in encryption before any HTTP data is sent; HTTP running over a TLS connection is what "HTTPS" means. TLS gives you three things at once: encryption (nobody else can read the data), integrity (nobody can silently modify it in transit), and authentication (you can verify you're actually talking to the server you think you are, via its certificate). Every production system in this course assumes HTTPS everywhere; there is essentially never a good reason to run plain HTTP for real traffic anymore.
Statelessness is the concept to hold onto here. Every time a later chapter says "the server doesn't store this," it is protecting the same property: any server can answer any request.
A teammate says "we don't need HTTPS for our internal admin dashboard, it's not public-facing." Do you agree?
"Sure, if it's not exposed to the internet, plain HTTP is fine internally."
"I'd still use TLS. 'Internal' traffic still crosses switches, routers, and often other teams' infrastructure; anyone with access to that network path can read or tamper with plaintext HTTP. TLS is cheap enough now (via a service mesh or a simple reverse proxy) that 'it's internal' isn't a strong enough reason to skip encryption and integrity guarantees."