HTTP and HTTPS: the web protocol and status codes explained
A complete guide to client-server communication, what TLS adds in HTTPS, and what each HTTP status code family means — from 200 to 500.
Every time you open an app, dashboard, or API, HTTP is usually underneath. Understanding the protocol — and its response codes — helps you debug faster, design clearer APIs, and explain incidents without guessing.
What is HTTP?
HTTP (HyperText Transfer Protocol) is an application-layer protocol that defines how a client (browser, mobile app, another server) requests resources from a server and how the server responds. It is stateless by design: each request stands alone, though cookies, sessions, or JWT tokens simulate continuity.
- Human-readable structure (method, path, headers, body).
- Request → response model: the client always initiates.
- Extensible via custom headers and content types.
GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json
{"id":42,"name":"Ana"}
What is HTTPS and why does it matter?
HTTPS is HTTP wrapped in TLS (Transport Layer Security). It encrypts traffic, authenticates the server via certificates, and protects data integrity in transit. Without HTTPS, passwords, tokens, and personal data can be intercepted on untrusted networks.
- Confidentiality: third parties cannot easily read traffic.
- Integrity: detects tampering with messages in transit.
- Server authentication: the certificate validates who is responding.
Request and response anatomy
A request includes method (GET, POST, PUT, PATCH, DELETE…), URL, protocol version, headers, and optionally a body. The response carries version, numeric status code, reason phrase, headers, and body (HTML, JSON, file, etc.).
Common methods
- GET — read a resource without expected side effects.
- POST — create a resource or trigger an action.
- PUT / PATCH — replace or partially update.
- DELETE — remove a resource.
- OPTIONS — discover allowed methods (useful with CORS).
Status codes: the server's vocabulary
The status code is a three-digit number. The first digit is the family: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. The phrase (e.g. "Not Found") is for humans; integrations care about the number.
2xx — Success
Request completed successfully. Standard response for a successful GET.
Resource created, common after POST. Often includes Location with the new URL.
Success with no response body. Common on DELETE or updates with no payload returned.
3xx — Redirection
Resource URL changed permanently. Search engines update their index.
Temporary redirect. Client may keep using the original URL later.
Cached resource is still valid; saves bandwidth on static assets.
4xx — Client error
Invalid syntax or malformed data. Check body and headers.
Missing authentication or invalid / expired token.
Authenticated but not allowed for that resource or action.
Route or resource does not exist. Also used to hide private resources.
Conflict with current state (e.g. duplicate email, stale version).
Valid JSON but business rules failed (semantic validation).
Rate limit exceeded. Respect Retry-After when present.
5xx — Server error
Unhandled server failure. Check logs and traces.
Proxy or gateway got an invalid response from upstream.
Server overloaded or in maintenance. May be temporary.
Upstream did not respond in time. Common with slow microservices.
API design best practices
- Use the code that matches the situation: do not return 200 with an error JSON body.
- Be consistent: same rules for auth, validation, and pagination.
- Document which codes each endpoint can return.
- In production, combine HTTP codes with clear messages and an internal error id.
Mastering HTTP and HTTPS is not memorizing numbers: it is knowing who failed (client, network, server) and what to do next. At NotFoundGroup we apply these standards in every API and web product we ship.