How REST APIs Work — Backend Development Tutorial

REST (Representational State Transfer) isn't a protocol or a library — it's an architectural style for designing APIs, described by Roy Fielding in 2000. Most APIs you've used, even ones that don't follow it strictly, borrow its core vocabulary: resources, identified by URLs, manipulated with HTTP methods.

Resources, not actions

A REST API models the things your application deals with — users, orders, articles — as resources, each with its own URL, rather than exposing actions as endpoint names.

Not REST-ish:              REST-ish:
GET /getUserById?id=42     GET /users/42
POST /createNewOrder       POST /orders
POST /deleteUser?id=42     DELETE /users/42

The resource is the noun (/users/42); the HTTP method is the verb (GET, DELETE). This consistency is what makes a well-designed REST API predictable — once you know the pattern, you can guess most of the API without reading docs.

The core constraints

Client-server separation — the client and server evolve independently, connected only by the API contract.
Statelessness — every request contains everything needed to process it (see the request/response lifecycle lesson); the server doesn't store client session state between requests.
Uniform interface — resources are addressed by URL and manipulated through a small, consistent set of methods.
Representations — a client doesn't get the resource itself, it gets a representation of it, almost always JSON today (originally REST was format-agnostic).
Cacheability — responses should indicate whether they can be cached, enabling standard HTTP caching (see the caching lesson later in this course).

A typical request/response pair

GET /api/orders/1024 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1024,
  "status": "shipped",
  "total": 49.99,
  "items": [{ "sku": "ABC123", "qty": 2 }]
}

Nesting and relationships

Related resources are commonly nested in the URL when the relationship is the point of the request:

GET /users/42/orders        — orders belonging to user 42
GET /users/42/orders/1024   — a specific order belonging to user 42

Deep nesting (/users/42/orders/1024/items/3/reviews) gets unwieldy fast — most APIs cap nesting at one or two levels and let deeper resources stand on their own (/items/3) once the immediate relationship has been established.

REST isn't a strict spec

There's no REST compliance checker — "RESTful" in practice means "follows these conventions closely enough to be predictable," and most production APIs bend a rule or two (a POST /orders/1024/cancel action endpoint is common even though it's not a pure resource operation). What matters is consistency within your own API, not dogmatic purity.

Next: how REST compares to GraphQL, an alternative approach that structures the client-server contract very differently.

Resources, not actions

A REST API models the things your application deals with — users, orders, articles — as resources, each with its own URL, rather than exposing actions as endpoint names.

Not REST-ish: REST-ish: GET /getUserById?id=42 GET /users/42 POST /createNewOrder POST /orders POST /deleteUser?id=42 DELETE /users/42

The core constraints

Client-server separation — the client and server evolve independently, connected only by the API contract.

Statelessness — every request contains everything needed to process it (see the request/response lifecycle lesson); the server doesn't store client session state between requests.

Uniform interface — resources are addressed by URL and manipulated through a small, consistent set of methods.

Representations — a client doesn't get the resource itself, it gets a representation of it, almost always JSON today (originally REST was format-agnostic).

Cacheability — responses should indicate whether they can be cached, enabling standard HTTP caching (see the caching lesson later in this course).

Nesting and relationships

Related resources are commonly nested in the URL when the relationship is the point of the request:

GET /users/42/orders — orders belonging to user 42 GET /users/42/orders/1024 — a specific order belonging to user 42

REST isn't a strict spec

Next: how REST compares to GraphQL, an alternative approach that structures the client-server contract very differently.