What is HTTP?
HTTP (HyperText Transfer Protocol) is the foundation of data communication on the web. It is a stateless, request-response protocol where the client (browser, mobile app, React frontend) sends a request and the server returns a response. Every interaction you have with a website — loading a page, submitting a form, fetching data — uses HTTP.
HTTPS adds a layer of security using TLS (Transport Layer Security), formerly SSL. TLS encrypts the data in transit so attackers cannot read or modify it (man-in-the-middle attacks). All production websites must use HTTPS. Modern browsers show a "Not Secure" warning for HTTP sites.
---
HTTP Request Anatomy
A complete HTTP request has three parts:
1. Request Line: GET /api/users/123?include=profile HTTP/1.1
- Method: GET
- Path: /api/users/123
- Query string: ?include=profile
- HTTP version: HTTP/1.1
2. Request Headers (key-value metadata):
| Header | Purpose | Example |
|---|---|---|
Host | Target server domain | Host: api.myapp.com |
Content-Type | Body format | application/json |
Authorization | Auth credentials | Bearer eyJhbGci... |
Cookie | Cookies to send | accessToken=... |
Accept | Expected response format | application/json |
Origin | CORS: request origin | https://myapp.com |
User-Agent | Client info | Mozilla/5.0... |
3. Request Body (optional — only for POST, PUT, PATCH):
{ "email": "user@example.com", "password": "secret123" }---
HTTP Response Anatomy
1. Status Line: HTTP/1.1 200 OK
2. Response Headers:
| Header | Purpose |
|---|---|
Content-Type | Format of the response body |
Set-Cookie | Instructs client to store a cookie |
Access-Control-Allow-Origin | CORS allowed origin |
Cache-Control | Caching instructions |
X-RateLimit-Remaining | Rate limit info |
Location | Redirect URL (for 3xx responses) |
3. Response Body:
{ "success": true, "data": { "id": "...", "name": "..." } }---
HTTP Methods
| Method | Purpose | Has Body | Idempotent | Safe |
|---|---|---|---|---|
GET | Retrieve resource | No | ✅ Yes | ✅ Yes |
POST | Create new resource | Yes | ❌ No | ❌ No |
PUT | Full replacement of resource | Yes | ✅ Yes | ❌ No |
PATCH | Partial update | Yes | Sometimes | ❌ No |
DELETE | Remove resource | No | ✅ Yes | ❌ No |
OPTIONS | CORS preflight, check capabilities | No | ✅ Yes | ✅ Yes |
HEAD | Same as GET but no body (check existence) | No | ✅ Yes | ✅ Yes |
Idempotent: Making the same request multiple times has the same effect as making it once. GET, PUT, DELETE are idempotent. POST is not (each POST creates a new resource).
---
HTTP Status Codes
1xx — Informational:
- 100 Continue: Server received request headers, client should send body
2xx — Success:
| Code | Name | When to Use |
|---|---|---|
| 200 | OK | Successful GET, PUT, PATCH, DELETE |
| 201 | Created | Resource created (POST) |
| 204 | No Content | Success but no body (DELETE) |
3xx — Redirection:
- 301 Moved Permanently: Old URL permanently redirected
- 302 Found: Temporary redirect
- 304 Not Modified: Cached version is still valid
4xx — Client Errors:
| Code | Name | When to Use |
|---|---|---|
| 400 | Bad Request | Malformed or invalid request |
| 401 | Unauthorized | Not authenticated |
| 403 | Forbidden | Authenticated but not authorised |
| 404 | Not Found | Resource does not exist |
| 409 | Conflict | Duplicate resource |
| 422 | Unprocessable Entity | Validation failed |
| 429 | Too Many Requests | Rate limited |
5xx — Server Errors:
| Code | Name | When to Use |
|---|---|---|
| 500 | Internal Server Error | Unexpected crash, bug |
| 502 | Bad Gateway | Proxy received invalid response |
| 503 | Service Unavailable | Server overloaded / maintenance |
| 504 | Gateway Timeout | Upstream service timed out |
---
HTTP/1.1 vs HTTP/2
| Feature | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Connection | One request per TCP connection | Multiple requests on one connection (multiplexing) |
| Header compression | No | Yes (HPACK) |
| Server push | No | Yes |
| Speed | Slower (head-of-line blocking) | Significantly faster |
| Adoption | Universal | Widely supported |
---
CORS Headers Explained
When a browser makes a cross-origin request, it first sends an OPTIONS preflight request to check if the server allows it:
OPTIONS /api/users HTTP/1.1
Origin: https://myapp.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, AuthorizationServer responds with:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400---
Stateless Nature of HTTP
HTTP is stateless — each request is completely independent. The server does not remember anything from the previous request. This is why we need:
- Cookies: Browser sends cookie automatically with every request to the same domain
- JWT tokens: Client attaches the token manually in the Authorization header
- Sessions: Server stores session data and client sends a session ID cookie
REST APIs leverage HTTP's stateless nature: each request must contain all information needed to process it.