Understanding HTTP and HTTPS

I remember when I first created an API. You call fetch(), get a response. Done? No. Until one day my API returned a 503, and I didn't understand why. From there I learned: HTTP is not just request-response.

This article dissects HTTP from the most fundamental level , which I wish I had when I was learning back then.

HTTP is Stateless , And It's Intentional

Every HTTP request stands on its own. The server doesn't remember you from the previous request. If you log in, then make another request , the server doesn't know who you are. That's why you need cookies, sessions, or JWT.

I used to think this was a weakness. Turns out it's a feature: being stateless allows the server to be scaled horizontally without the hassle of shared sessions.

Client-Server Architecture , But Don't Underestimate It

The client (browser, app, other services) sends a request. The server processes it and returns a response. Simple. But what makes it complex is: data types, encoding, caching, compression, redirects, and security , all handled through HTTP headers.

HTTP/1.1 vs HTTP/2 , Faster, But Different

HTTP/1.1: one TCP connection for one request. If there are 6 resources, it needs 6 connections. HTTP/2: multiplexing , multiple requests in one connection, binary framing (lighter), header compression.

What I often see: people deploy HTTP/2 but don't change how they write code. The maximum benefit comes if you also use server push and streams.

HTTPS: Not an Option, But an Obligation

Standard HTTP sends data in plain text , anyone on the same network can read it. HTTPS adds SSL/TLS encryption. Nowadays, if your API isn't HTTPS, it's considered insecure by browsers.

• Encryption , your data can't be read by others
• Integrity , data doesn't change during transit
• Authentication , you know the server you're contacting is the right one

Anatomy of an HTTP Message , The Same Structure for Request and Response

Every HTTP message has 3 parts: start-line (method + path or status code), headers (metadata), and body (actual data).

What's often forgotten: headers are very important , Content-Type, Cache-Control, Authorization, CORS. Setting headers incorrectly can make your API vulnerable or slow.

HTTP Methods , Idempotency Is an Important Concept

You need to know which methods are safe to call repeatedly (idempotent) and which are not:

• GET, HEAD, PUT, DELETE , idempotent. Call it 1x or 100x, the effect is the same
• POST, PATCH , not idempotent. POST creates a new resource every time

HTTP Status Codes , The Universal Language from Server to Client

Status codes are the server's way of saying: what happened to your request? Not all errors are 500. Not all successes are 200.

• 2xx , success (200 OK, 201 Created, 204 No Content)
• 3xx , redirect (301 Moved, 304 Not Modified)
• 4xx , client error (400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests)
• 5xx , server error (500 Internal, 502 Bad Gateway, 503 Service Unavailable)

Conclusion: HTTP Is More Than Just Calling an API

HTTP is a protocol that looks simple but is full of details. Stateless, status codes, headers, methods , each has design consequences. A good engineer doesn't just know how to call an API, but understands what happens behind the scenes.