HTTP and REST

Every page you load and every API call your app makes goes over HTTP. Understanding the request/response cycle and the conventions of REST is the foundation of web development.

The Request/Response Cycle

A client sends an HTTP request: a method, a path, headers, and an optional body. The server replies with a response: a status code, headers, and an optional body. Both sides are stateless — every request stands on its own, which is why apps use cookies or tokens to remember who you are.

HTTP Methods

The method tells the server what you want to do:

GET — read a resource (no side effects)
POST — create a new resource
PUT — replace a resource entirely
PATCH — update part of a resource
DELETE — remove a resource

GET and PUT are idempotent: calling them twice has the same effect as calling them once. This matters for retries on flaky networks.

Status Codes

Three-digit numbers in five families:

2xx success (200 OK, 201 Created, 204 No Content)
3xx redirection (301 Moved Permanently, 304 Not Modified)
4xx client error (400 Bad Request, 401 Unauthorized, 404 Not Found)
5xx server error (500 Internal Server Error, 503 Service Unavailable)

Returning the right code is part of designing a good API.

REST Conventions

REST (Representational State Transfer) is a set of conventions, not a strict standard. The core idea: model your application as a collection of resources, each with a URL, and use HTTP methods to act on them. A typical REST API looks like:

GET    /users          list users
POST   /users          create a user
GET    /users/42       fetch user 42
PUT    /users/42       replace user 42
DELETE /users/42       delete user 42

Predictable URLs and standard methods make APIs easy to learn and easy to cache.

Try It Yourself

Parse an HTTP request that includes headers separated by \r\n
Map each 2xx, 4xx, and 5xx code in the example to whether a retry is appropriate
Sketch the REST endpoints for a "playlists" resource that contains nested "tracks"