Web & Backend
HTTP and HTTPS
HTTP is the protocol a browser, app, or one server uses to ask another server for something: it sends a request (a method, a path, some headers, maybe a body) and gets back a response (a status code, headers, maybe a body). It is stateless by design, so each request stands alone unless the client attaches something like a cookie or a token. HTTPS is the same protocol carried over an encrypted TLS connection instead of a plain one, so a third party on the network can see that a connection happened but not read or alter what was said.
Why it matters
- It underlies almost every network call an application makes
- A browser rendering a page, a mobile app hitting an API, and one backend service calling another usually all speak HTTP underneath, even when a framework hides the details.
- Status codes carry the outcome of a request without parsing the body
- A client can tell success from a retryable failure from a permanent one just from the numeric code — 200, 429, and 500 mean very different things to a retry loop.
- HTTPS is now the assumed default, not an optional extra
- Browsers label plain-HTTP pages as not secure, and features like clipboard access, geolocation, and service workers refuse to run on an insecure origin.
- Caching, load balancers, and CDNs all key off HTTP semantics
- Headers such as Cache-Control and ETag are how a CDN decides whether to serve a stored copy or forward the request to the origin server.
Anatomy of a request and a response
A request has a method (GET, POST, and so on), a path, a set of headers (metadata like the content type or an auth token), and an optional body. A response mirrors that shape: a status line with a numeric code, headers, and an optional body. Nothing about this exchange remembers the previous one — HTTP itself has no concept of a logged-in user or a shopping cart, which is why applications layer cookies, sessions, or tokens on top of it to fake continuity.
GET /api/orders/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60
{"id": 42, "status": "shipped"}Methods, status codes, and idempotency
GET reads without side effects and is safe to retry, cache, or prefetch. POST typically creates something and is not safe to repeat blindly. PUT and DELETE are meant to be idempotent — sending the same PUT twice should leave the resource in the same state as sending it once, which matters when a request times out and a client has to decide whether retrying is safe. Status codes group into families: 2xx is success, 3xx is a redirect, 4xx means the client got something wrong (a bad request, a missing resource, no permission), and 5xx means the server failed even though the request was fine.
What HTTPS actually changes
HTTPS wraps HTTP in TLS: the client and server perform a handshake, agree on a shared key, and verify the server's identity against a certificate signed by a trusted authority. Everything after that — headers, body, cookies — travels encrypted, so an attacker on the same network can see that a connection to a given server exists but not read or modify what is sent. It is worth being precise about what it does not hide: the server's hostname is typically still visible to anyone watching the network (via DNS lookups and, historically, the TLS handshake's SNI field), so HTTPS protects the content and integrity of a request, not the fact that it happened.
Mistakes people make here
- Returning HTTP 200 with an error described only inside the JSON body
- It works, but it defeats the point of status codes: generic HTTP tooling (caches, monitoring, retry logic) reads the status line, not the body, so a real failure gets treated as a success everywhere except inside the one client that bothers to inspect the payload.
- Using GET for an action that changes data
- Browsers, proxies, and crawlers are allowed to retry, cache, or prefetch GET requests because the method promises no side effects. A GET that deletes something can be triggered by a link preview or a retried connection, not just a user's click.
- Assuming HTTPS hides which site someone is visiting
- The connection's content and cookies are encrypted, but the destination hostname is usually still visible to the network via DNS and, in most current deployments, the handshake itself — HTTPS is about integrity and confidentiality of the exchange, not anonymity about who you're talking to.
- Treating PUT and DELETE as safe to skip retry logic for
- They're supposed to be idempotent, but that's a convention the server has to actually implement — a poorly written DELETE endpoint that errors on a second call breaks the exact retry behavior the method was designed to allow.
Strengths and trade-offs
Where it is strong
- Stateless requests are simple to scale horizontally — any server can handle any request with no shared session state required.
- A small, well-understood set of methods and status codes gives clients and servers a shared vocabulary without a custom protocol.
- Decades of infrastructure — proxies, caches, load balancers, browsers, debugging tools — already understand it natively.
- The protocol has evolved (HTTP/1.1 to HTTP/2 to HTTP/3) without breaking the request/response model applications are written against.
The trade-offs
- Statelessness means identity and session info has to be resent (via a cookie or token) on every request, which is small but real overhead.
- HTTP/1.1 can suffer head-of-line blocking on a single TCP connection; HTTP/2 multiplexes streams, and HTTP/3 moves to QUIC over UDP specifically to fix this further.
- Text-based framing is verbose compared to binary protocols like gRPC, which is why very high-throughput internal service calls sometimes skip HTTP/JSON entirely.
- The TLS handshake adds latency to the first connection, though session resumption and HTTP/3's faster handshake reduce this in practice.
Who needs this
Foundational for anyone building or consuming a web or mobile backend — status codes, methods, and headers are baseline literacy, not an advanced topic.
Questions about http and https
- Is HTTPS necessary for a simple site with no logins?
- Yes. Browsers now flag plain HTTP as not secure, and HTTPS protects against on-path tampering and eavesdropping even when there's no login form — for example, it stops an attacker on a shared network from injecting content into the page.
- What actually changed between HTTP/1.1, HTTP/2, and HTTP/3?
- HTTP/2 introduced binary framing and let multiple requests share one TCP connection without blocking each other. HTTP/3 goes further by replacing TCP with QUIC (over UDP), which avoids TCP-level head-of-line blocking and speeds up connection setup, particularly on unreliable networks.
- Why do some APIs return 200 with an error inside the response body?
- Usually to simplify client-side handling in one specific client, or because the team didn't standardize on status codes early on. It's a common but genuinely debated shortcut — it works, but it breaks assumptions that generic HTTP tooling makes about what a 200 means.
- Does HTTPS hide the domain I'm visiting from my internet provider?
- Generally no. DNS lookups and, in most deployments, the TLS handshake's server name still reveal the hostname to anyone watching the network; the path, query parameters, and body are what's actually encrypted and hidden.