How the Web Works: HTTP, REST & APIs

When you type a URL and press Enter, a dozen protocols coordinate in milliseconds. Senior engineers can trace this journey from DNS lookup to rendered pixels — and more importantly, they know where performance and security problems hide in each step.

What Happens When You Type a URL

1. URL Parsing         → Browser parses scheme, host, path, query, fragment
2. DNS Resolution      → Domain name → IP address
3. TCP Connection      → Three-way handshake (SYN → SYN-ACK → ACK)
4. TLS Handshake       → Certificate verification, key exchange (HTTPS)
5. HTTP Request        → Browser sends GET request with headers
6. Server Processing   → Server generates response
7. HTTP Response       → Status code, headers, body
8. Parsing & Rendering → HTML → DOM → CSSOM → Layout → Paint → Composite

DNS Resolution

Browser cache → OS cache → Router cache → ISP DNS → Root DNS → TLD DNS → Authoritative DNS
                                                                              ↓
                                                                      IP: 93.184.216.34

Each step is a potential cache hit. First visits resolve the full chain; subsequent visits hit local caches. dns-prefetch and preconnect hints move this cost earlier:

<link rel="dns-prefetch" href="https://api.example.com" />
<link rel="preconnect" href="https://cdn.example.com" crossorigin />

TCP Three-Way Handshake

Client                    Server
  │── SYN ──────────────────▶│    1. Client requests connection
  │◀────────── SYN-ACK ──────│    2. Server acknowledges + requests back
  │── ACK ──────────────────▶│    3. Client confirms — connection open

Each round trip adds latency. HTTP/2 multiplexes over one connection; HTTP/3 (QUIC) runs over UDP to eliminate head-of-line blocking.

TLS Handshake (HTTPS)

Client                              Server
  │── ClientHello (ciphers, TLS version) ──▶│
  │◀── ServerHello (chosen cipher, cert) ───│
  │── Verify cert, exchange keys ──────────▶│
  │◀── Finished ───────────────────────────│
  │    🔒 Encrypted connection established  │

TLS 1.3 reduces this to one round trip (vs two in TLS 1.2). The certificate chain is verified against the browser's trusted CA store.

HTTP Fundamentals

HTTP Methods

Method	Purpose	Idempotent	Safe	Body
`GET`	Retrieve a resource	Yes	Yes	No
`POST`	Create a resource / submit data	No	No	Yes
`PUT`	Replace a resource entirely	Yes	No	Yes
`PATCH`	Partially update a resource	No*	No	Yes
`DELETE`	Remove a resource	Yes	No	Optional
`HEAD`	Same as GET but no response body	Yes	Yes	No
`OPTIONS`	Discover supported methods (CORS preflight)	Yes	Yes	No

Idempotent: Multiple identical requests produce the same result. PUT /users/1 with the same body always results in the same state. POST /users creates a new user each time.

Safe: Doesn't modify server state. GET and HEAD should never have side effects.

HTTP Status Codes

Range	Category	Common Codes
1xx	Informational	`101 Switching Protocols` (WebSocket upgrade)
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`, `409 Conflict`, `422 Unprocessable Entity`, `429 Too Many Requests`
5xx	Server Error	`500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable`, `504 Gateway Timeout`

HTTP Headers

Request Headers:

GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGc...
Content-Type: application/json
Cache-Control: no-cache
User-Agent: Mozilla/5.0 ...
Accept-Encoding: gzip, br
Cookie: session=abc123
Origin: https://app.example.com

Response Headers:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1234
Cache-Control: public, max-age=3600, stale-while-revalidate=86400
ETag: "abc123"
Set-Cookie: session=xyz; HttpOnly; Secure; SameSite=Strict
Access-Control-Allow-Origin: https://app.example.com
Content-Encoding: br
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff

Key Security Headers:

Header	Purpose
`Strict-Transport-Security` (HSTS)	Force HTTPS for all future requests
`Content-Security-Policy` (CSP)	Restrict where scripts/styles/images can load from
`X-Content-Type-Options: nosniff`	Prevent MIME-type sniffing
`X-Frame-Options`	Prevent clickjacking via iframes
`Referrer-Policy`	Control what's sent in the Referer header
`Permissions-Policy`	Restrict browser features (camera, geolocation)

Caching Headers

Cache-Control: public, max-age=31536000, immutable
  → CDN and browser can cache for 1 year, never revalidate
 
Cache-Control: private, no-cache
  → Only browser can cache, must revalidate with server every time
 
Cache-Control: no-store
  → Never cache (sensitive data)
 
ETag: "v1.2.3"
  → Server sends a version tag; browser sends If-None-Match on next request
  → Server responds 304 Not Modified if unchanged (saves bandwidth)

HTTPS

HTTPS = HTTP + TLS encryption. It provides:

Confidentiality — Data encrypted in transit (can't be read by intermediaries)
Integrity — Data can't be modified without detection
Authentication — Certificate proves server identity

Modern browsers flag HTTP sites as "Not Secure." Service Workers, Geolocation, and other sensitive APIs require HTTPS.

REST API Design

REST (Representational State Transfer) is a set of conventions for API design:

Resource-Based URLs

GET    /api/users          → List all users
POST   /api/users          → Create a user
GET    /api/users/42       → Get user 42
PUT    /api/users/42       → Replace user 42
PATCH  /api/users/42       → Update user 42 partially
DELETE /api/users/42       → Delete user 42
 
GET    /api/users/42/posts → List user 42's posts (nested resource)

REST Principles

Stateless — Each request contains all information needed; no server-side session
Resource-based — URLs represent nouns (resources), not verbs
Uniform interface — Standard HTTP methods for CRUD operations
Client-server separation — Frontend and backend evolve independently
Cacheable — Responses declare cacheability via headers

REST vs Other API Styles

Feature	REST	GraphQL	gRPC
Protocol	HTTP	HTTP (typically POST)	HTTP/2
Data format	JSON (usually)	JSON	Protocol Buffers
Fetching	Fixed structure per endpoint	Client specifies shape	Method-based RPC
Over-fetching	Common (fixed responses)	Eliminated (query what you need)	N/A
Under-fetching	Requires multiple requests	Single query	N/A
Caching	HTTP caching (simple)	Complex (query-based)	Limited
Real-time	Polling / WebSocket	Subscriptions	Streaming
Best for	Simple CRUD, public APIs	Complex data graphs, mobile	Microservice-to-microservice

SOAP (Legacy)

SOAP uses XML for request/response with a strict contract (WSDL). It's largely replaced by REST/GraphQL in modern web development but still exists in enterprise/banking systems:

<soap:Envelope>
  <soap:Body>
    <GetUser>
      <UserId>42</UserId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

REST is preferred for web frontends because:

Simpler (JSON vs XML)
Cacheable (HTTP-native caching)
Lighter payloads
Works naturally with browser fetch API

The Complete Request Lifecycle

User clicks link
    │
    ▼
Browser checks caches (Service Worker → HTTP cache → DNS cache)
    │
    ▼
DNS resolution (if cache miss)
    │
    ▼
TCP + TLS connection (or reuse existing)
    │
    ▼
HTTP request with headers
    │
    ▼
Server processes request
    │
    ▼
HTTP response with status + headers + body
    │
    ▼
Browser parses response
    │
    ├── HTML → DOM tree
    ├── CSS → CSSOM
    ├── JS → Execute (may modify DOM)
    │
    ▼
Layout → Paint → Composite → Pixels on screen

Interview Signal

Senior candidates demonstrate:

Full journey — Can trace URL to pixels: DNS → TCP → TLS → HTTP → Parse → Render, with performance implications at each step
HTTP method semantics — Idempotency, safety, correct method for each CRUD operation
Header fluency — Cache-Control directives, security headers, CORS headers, ETag/If-None-Match
REST conventions — Resource-based URLs, proper status codes, statelessness, when to choose GraphQL/gRPC instead
HTTPS understanding — What TLS provides (confidentiality, integrity, authentication), why HTTP is insufficient