REST
REST, short for Representational State Transfer, is an architectural style for building HTTP APIs around resources, representations, and stateless client-server interactions.
It is still one of the most satisfying ways to make backend systems legible: the nouns are visible, the verbs are familiar, and a well-designed API can often be understood by simply reading its routes, payloads, and status codes.
Core ideas
- Resources are modeled as stable concepts such as users, projects, tasks, or documents.
- HTTP methods such as
GET,POST,PATCH, andDELETEcommunicate intent through a common interface. - Requests remain stateless, so each call carries the context the server needs to process it.
- Representations such as JSON payloads let clients read and update server-side state without coupling themselves to the server internals.
Where it fits
REST works especially well when an API needs predictable CRUD behavior, straightforward authorization boundaries, and endpoint contracts that many clients can understand without learning a custom query language.
It is the dominant style across the vault’s application notes, including most FastAPI services and the stacks documented in Status Alganize and Study Duel.
Design pressures
- Resource naming matters. Clean nouns usually age better than RPC-like endpoints.
- HTTP semantics matter. Caching, idempotency, and status codes become part of the architecture, not just transport details.
- Versioning, filtering, pagination, and auth shape how pleasant the API is to maintain.
- Frontend-heavy applications sometimes need aggregation layers or generated clients to keep many small requests manageable.
Trade-offs
- REST stays clear for many systems, but composite frontend views can require multiple requests or backend-for-frontend shaping.
- Teams often call any JSON API “REST” even when the design is only loosely resource-oriented.
- Once clients need highly tailored graph traversals, GraphQL can become more attractive.