REST APIs Explained: How the Frontend Actually Talks to the Backend

"REST API" gets used loosely to mean "any API that returns JSON over HTTP" — which misses the actual point. REST (Representational State Transfer) is a specific set of architectural constraints, and each one is solving a real, nameable problem.

The constraints that actually matter day to day

• Statelessness — every request contains everything the server needs to understand it; the server doesn't remember anything about the client between requests. This is exactly why authentication tokens get sent on every single request, rather than the server "remembering" you're logged in from a previous call.
• Resource-based URLs — a URL identifies a resource (a noun), not an action (a verb): `/orders/42`, not `/getOrder?id=42`. The HTTP method carries the verb: GET to read it, DELETE to remove it, PUT to replace it.
• Uniform interface via HTTP methods and status codes — GET never has side effects, PUT is idempotent (calling it twice with the same body produces the same result as calling it once), and the response status code communicates outcome in a standardized, method-independent way — the same vocabulary the HTTP post in this series covered.
• Cacheability — because GET is defined to have no side effects, its responses can be safely cached by the browser, a CDN, or an intermediate proxy without risk of serving stale writes.

A concrete example of what this buys you

GET    /orders/42       → fetch order 42
PUT    /orders/42       → replace order 42 entirely
PATCH  /orders/42       → partially update order 42
DELETE /orders/42       → remove order 42
GET    /orders/42/items → the items belonging to order 42

Once resources and methods follow this convention consistently, an API becomes genuinely predictable — a developer who's never seen this specific endpoint can correctly guess how to fetch an order's items, because the pattern is uniform across the whole API, not because they memorized this one case.

Where GraphQL fits, briefly

REST's resource-per-URL model has a real cost: fetching a nested object graph (a user, their orders, each order's items) can mean multiple round-trips or an endpoint custom-built for that one specific shape. GraphQL solves that particular problem directly — the client specifies exactly the shape of data it needs in one request — at the cost of REST's simplicity and its built-in HTTP-level cacheability. A full comparison is worth its own post later in this series; the short version is that they're solving overlapping but genuinely different problems.