5. Web Concepts

Sessions

HTTP is stateless — each request is independent. Sessions allow servers to maintain state across multiple requests from the same client.

Approaches:

Cookie-based sessions: Server stores session data; client holds a session ID cookie. On each request, the server looks up the session by ID.
JWT (JSON Web Tokens): Client holds a signed token containing user info and claims. No server-side session store needed. Tokens can be verified without DB lookup.
Token-based (opaque tokens): Server issues a random token; client sends it via Authorization header. Server looks up the token in a store (Redis, DB).

# Session-based authentication
POST /login { "username": "alice", "password": "***" }
Server validates credentials, creates session, returns:
Set-Cookie: session_id=abc123; HttpOnly; Secure

GET /profile
Cookie: session_id=abc123
Server looks up session, finds user_id=42, returns profile

Serialization

Serialization converts an in-memory object into a format that can be stored or transmitted. Deserialization reverses this.

Format	Human-Readable	Binary	Schema Required	Performance
JSON	Yes	No	No	Moderate
XML	Yes	No	Optional	Slower
Protocol Buffers	No	Yes	Yes (.proto)	Fast
Avro	No	Yes	Yes (inline/separate)	Fast
MessagePack	No	Yes	No	Fast

# JSON Serialization (Python dict → JSON string)
{"user": {"id": 42, "name": "Alice", "roles": ["admin"]}}

# Protocol Buffers (compact binary, ~40% smaller than JSON)
message User { int32 id = 1; string name = 2; repeated string roles = 3; }

CORS (Cross-Origin Resource Sharing)

CORS is a browser security mechanism that restricts web pages from making requests to a different domain than the one that served the page. The server specifies allowed origins via HTTP headers.

# Server response header to allow cross-origin requests
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization

# Preflight request (OPTIONS) for non-simple requests
OPTIONS /api/data
Origin: https://myapp.com
Access-Control-Request-Method: DELETE

Idempotency

An operation is idempotent if performing it multiple times has the same effect as performing it once. Crucial for distributed systems where retries are common.

GET, PUT, DELETE are idempotent by nature.
POST is generally not idempotent (creates new resources each time).
Idempotency key: Clients send a unique key; servers detect duplicates and skip processing.

Exercise: Your API receives duplicate payment requests due to network retries. Design an idempotency mechanism using an idempotency key. How do you store it? When do you expire it? What happens if the server crashes mid-processing?