/wiki / understanding-http-for-backend-engineers

Understanding Http For Backend Engineers — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Understanding Http For Backend Engineers — 7 concepts. Start here to navigate understanding-http-for-backend-engineers.

Core Concepts

true — concept
true — concept
true — concept
true — concept
true — concept
true — concept
true — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

CORS

2026-04-12T00:00:00.000Z

The Problem

Browsers enforce the Same-Origin Policy by default—scripts on domain A cannot access resources on domain B. This protects users from malicious cross-site requests, but blocks legitimate API calls between domains.

Core Idea

CORS (Cross-Origin Resource Sharing) is a mechanism that lets servers explicitly declare which domains (origins) can access their resources and under what conditions.

How It Works

Simple Request Flow

For simple requests (GET/POST/HEAD with standard headers):

Client sends request with Origin header
Server checks policy, responds with Access-Control-Allow-Origin
Browser allows/blocks response based on header

Pre-flight Request Flow

For non-simple requests (PUT, DELETE, custom headers, non-standard Content-Type):

Browser sends OPTIONS request first (pre-flight)
Server responds with allowed methods, headers, and origins
Browser caches this (via Access-Control-Max-Age)
Then sends actual request

Key Headers

Header	Purpose
`Origin`	Client’s domain (sent by browser)
`Access-Control-Allow-Origin`	Allowed origins (server)
`Access-Control-Allow-Methods`	Allowed methods (server)
`Access-Control-Allow-Headers`	Allowed headers (server)
`Access-Control-Max-Age`	Cache duration for pre-flight

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
            .allowedOrigins("http://localhost:5173")
            .allowedMethods("GET", "POST", "PUT", "DELETE")
            .allowedHeaders("*")
            .allowCredentials(true);
    }
}

Key Properties

Server controls access—not the client
Pre-flight caching reduces overhead
Credentials require specific origin (not ’*’)

Connections

Related to: HTTP Headers (uses headers for negotiation: Access-Control-Allow-Origin)
Builds on: HTTP Methods (OPTIONS is the pre-flight method)
Related to: HTTP Status Codes (401, 403 errors appear in CORS failures)
Related to: Statelessness (CORS requests must include all auth per request)

Edge Cases & Gotchas

CORS errors in browser console ≠ server error; request reached server
Preflight required for PUT, DELETE, PATCH methods
Authorization header triggers pre-flight (custom header)
Misconfiguration appears as “blocked by CORS policy”

HTTP Headers

2026-04-12T00:00:00.000Z

The Problem

The message body carries the core data, but the request/response needs metadata—content type, authentication, caching rules, client info—that shouldn’t be mixed with the payload.

Core Idea

Headers are key-value pairs providing metadata about the request or response. They’re like the address on a parcel—metadata that lets intermediaries process messages without opening the body.

Connections

Built from: HTTP (the message structure)
Related to: HTTP Status Codes (response metadata)
Related to: CORS (uses headers for cross-origin control)
Related to: HTTP Methods (define what the request wants to do)

Edge Cases & Gotchas

Custom headers can use X- prefix but this is now discouraged
Headers are case-insensitive but conventionally Title-Case
Large header values can cause issues with some proxies

HTTP Methods

2026-04-12T00:00:00.000Z

The Problem

Clients need a standardized way to indicate what action they want the server to perform on a resource.

Core Idea

HTTP methods (also called verbs) define the intent of a request. Each method has semantic meaning that clients and servers can rely on.

How It Works

Method	Intent	Side Effects
GET	Fetch data	None (safe)
POST	Create resource	May create
PUT	Replace entirely	Idempotent
PATCH	Partial update	May mutate
DELETE	Remove	Idempotent

@RestController
@RequestMapping("/api/notes")
public class NoteController {
    @GetMapping("/{id}")        // Fetch
    @PostMapping               // Create
    @PutMapping("/{id}")       // Replace
    @PatchMapping("/{id}")     // Partial update
    @DeleteMapping("/{id}")    // Remove
}

Key Properties

Safe methods: GET, HEAD, OPTIONS — do not modify server state
Idempotent methods: GET, PUT, DELETE — same result despite repeated calls
Non-idempotent: POST, PATCH — repeated calls produce different results

Connections

Built from: HTTP (the protocol that defines these)
Related: HTTP Status Codes (codes pair with methods)
Contrasts with: Circuit Switching (connection-held methods)
Related: Statelessness (methods are independent requests)

Edge Cases & Gotchas

Use PATCH for most updates—PUT replaces entirely
POST creates new resources; calling twice typically creates two records
DELETE is idempotent—deleting already-deleted resource returns same response

HTTP Status Codes

2026-04-12T00:00:00.000Z

The Problem

Clients need a standardized way to understand whether their request succeeded, failed, or requires further action—without parsing custom error messages.

Core Idea

HTTP status codes are standardized three-digit numbers that communicate the outcome of a request. The first digit indicates the category.

How It Works

Range	Meaning	Key Codes
1xx	Informational	100 Continue, 101 Switching Protocols
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection	301 Moved Permanently, 302 Found, 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 Unavailable

Common Codes Explained

200 OK: Request succeeded, body follows
201 Created: Resource successfully created (POST)
204 No Content: Success, no body to return (DELETE, OPTIONS)
400 Bad Request: Client sent invalid data
401 Unauthorized: No/invalid authentication
403 Forbidden: Authenticated but insufficient permission
404 Not Found: Resource doesn’t exist
429 Too Many Requests: Rate limit exceeded

@GetMapping("/{id}")
public ResponseEntity<Note> getNote(@PathVariable Long id) {
    return noteService.findById(id)
        .map(ResponseEntity::ok)
        .orElse(ResponseEntity.notFound()); // 404
}
 
@PostMapping
public ResponseEntity<Note> createNote(@RequestBody NoteRequest req) {
    Note note = noteService.create(req);
    return ResponseEntity.status(HttpStatus.CREATED).body(note); // 201
}

Connections

Built from: HTTP (response structure)
Related to: HTTP Headers (error responses may include detail in headers)
Part of: HTTP Methods (which codes pair with which methods - 201 with POST, 204 with DELETE)
Related to: CORS (403 Forbidden is CORS policy violation)

Edge Cases & Gotchas

401 vs 403: 401 = not authenticated, 403 = authenticated but no permission
204 has no body—don’t try to return JSON with 204
304 must not include response body (browser uses cached version)

HTTP Versions

2026-04-12T00:00:00.000Z

The Problem

Early HTTP was inefficient—each request opened a new TCP connection, adding latency. The protocol needed evolution to handle modern web scale.

Core Idea

HTTP has evolved through four major versions, each adding performance and capability improvements while maintaining backward compatibility at the application level.

How It Works

HTTP 1.0 (1991)

Each request opens a new TCP connection
No persistent connections—significant latency
Text-based protocol

HTTP 1.1 (1997)

Persistent connections: Multiple requests over one TCP connection
Chunked transfer encoding
Better caching (ETag, If-None-Match)
Pipelining (later disabled due to HOL blocking)

HTTP 2.0 (2015)

Multiplexing: Multiple requests/responses in parallel over one connection
Binary framing (more efficient to parse than text)
Header compression (HPACK)
Server Push (server sends resources before client asks)

HTTP 3.0 (2022)

Built on QUIC (runs over UDP, not TCP)
Faster connection establishment
No head-of-line blocking (even with packet loss)
Continues multiplexing benefits

Key Properties

Version	Transport	Key Feature
1.0	TCP/new	None (baseline)
1.1	TCP/persistent	Reusable connections
2.0	TCP/binary	Multiplexing, server push
3.0	QUIC/UDP	No HOL blocking

Connections

Evolves from: HTTP (the protocol)
Relates to: Packet Switching (underlying transport mechanism)
Related to: HTTP Headers (HPACK compression in HTTP/2)
Related to: CORS (pre-flight benefits from version capabilities)

Edge Cases & Gotchas

HTTP/2 doesn’t require encryption (but browsers only support h2 over TLS)
HTTP/3 still has limited server support
HTTP/1.1 pipelining was disabled due to bugs—HTTP/2 fixed this

HTTP

2026-04-12T00:00:00.000Z

The Problem

Without a standardized protocol, every client and server would need custom communication logic. The internet would fragment into isolated systems that cannot interoperate.

Core Idea

HTTP (Hypertext Transfer Protocol) is the standardized language that enables any client—a browser, mobile app, Postman, or CLI tool—to communicate with any server, regardless of technology stack.

How It Works

HTTP operates at the Application Layer (Layer 7) of the OSI model, using TCP as its transport protocol. The client initiates communication by sending a request, and the server responds with an appropriate message.

Key architectural decisions:

Statelessness: Each request is independent; the server retains no memory of past interactions
Client-Server Model: Communication is always client-initiated; the server cannot spontaneously send data
Standardized Message Format: HTTP defines consistent structures for requests and responses

Key Properties

Runs over TCP (reliable delivery) for HTTP 1.x/2.x, over QUIC/UDP for HTTP 3.0
Text-based (1.x) or binary (2.x, 3.x) message framing
Extensible via headers without protocol changes
Works with persistent connections (1.1+) for efficiency

Connections

Built from: Packet Switching (transported as network packets)
Related: Circuit Switching (alternative transport paradigm)
Contrasts with: WebSocket (bidirectional, server-can-send)
Related: HTTPS (encrypted HTTP variant)

Edge Cases & Gotchas

HTTP is text-based in 1.x—binary data must be encoded (Base64)
Without state management, every request must re-authenticate
Servers cannot push data to clients without WebSockets or polling

Statelessness

2026-04-12T00:00:00.000Z

The Problem

Server memory grows without bound if every interaction must be preserved. Scaling becomes impossible when specific servers must handle specific clients.

Core Idea

Each HTTP request contains all information needed for the server to process it. The server has no memory of past requests—every interaction is independent.

How It Works

When a client requests a resource, the request includes authentication credentials, headers, URL, and body. After the server responds, it forgets the interaction entirely. The next request is treated as completely new.

// Every request must include auth - server has no memory
@GetMapping("/api/users/{id}")
public ResponseEntity<User> getUser(
    @PathVariable Long id,
    @RequestHeader("Authorization") String token) {
    // Token must be sent every time - no session from previous requests
    return ResponseEntity.ok(userService.findById(id));
}

Key Properties

Simplicity: No session store, cleanup, or synchronization needed
Scalability: Any server can handle any request; load balancing is trivial
Resilience: Server crash doesn’t affect client state—no session to restore

Connections

Built from: HTTP (the protocol that enforces this property)
Related: REST Architecture (stateless APIs follow HTTP pattern)
Contrasts with: Circuit Switching (stateful connection holding)
Related: Broadcast Links (one-to-many pattern)

Edge Cases & Gotchas

Stateful applications require tokens/cookies sent with every request
Without state management, users would re-authenticate on every action
Performance cost of re-sending data is acceptable given scale benefits

/wiki / understanding-http-for-backend-engineers

Understanding Http For Backend Engineers — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

CORS

The Problem

Core Idea

How It Works

Simple Request Flow

Pre-flight Request Flow

Key Headers

Key Properties

Connections

Edge Cases & Gotchas

HTTP Headers

The Problem

Core Idea

Categories

Request Headers

General Headers

Representation Headers

Security Headers

Connections

Edge Cases & Gotchas

HTTP Methods

The Problem

Core Idea

How It Works

Key Properties

Connections

Edge Cases & Gotchas

HTTP Status Codes

The Problem

Core Idea

How It Works

Common Codes Explained

Connections

Edge Cases & Gotchas

HTTP Versions

The Problem

Core Idea

How It Works

HTTP 1.0 (1991)

HTTP 1.1 (1997)

HTTP 2.0 (2015)

HTTP 3.0 (2022)

Key Properties

Connections

Edge Cases & Gotchas

HTTP

The Problem

Core Idea

How It Works

Key Properties

Connections

Edge Cases & Gotchas

Statelessness

The Problem

Core Idea

How It Works

Key Properties

Connections

Edge Cases & Gotchas