Backend
REST
An architectural style that models the API as resources (nouns) addressed by URLs and manipulated with HTTP verbs — GET, POST, PUT, PATCH, DELETE — plus status codes and statelessness. It is simple, cacheable and universally understood. The weakness is over- and under-fetching: fixed endpoints often return too much or force several round-trips.
Purpose
REST (Representational State Transfer) is a set of conventions for building HTTP APIs around resources — nouns such as /users/42 — that clients read and change with the standard HTTP verbs. It exists to make APIs predictable: one small vocabulary of methods and status codes works across every endpoint, so clients, caches and tooling can be written once and reused everywhere.
When to Use It
It is the default for public web and mobile APIs, CRUD-style services, and anything that benefits from HTTP caching and a low barrier to entry. If your data maps cleanly onto resources and consumers are diverse — browsers, third parties, curl — REST is almost always the right first choice.
Reach for something else when you need real-time push (WebSockets/SSE), rigid typed contracts between internal services (gRPC), or highly variable client data needs (GraphQL).
Trade-offs
The main weakness is over- and under-fetching: fixed response shapes often return fields a client does not need, or force several round-trips to assemble one screen. Evolving payloads without breaking clients also takes discipline. In return you get simplicity, uniformity and effectively free HTTP caching.
Implementation
Model resources as plural nouns (/orders, /orders/{id}), use verbs correctly — GET is safe and idempotent, POST creates, PUT/PATCH update, DELETE removes — and return accurate status codes (200, 201, 404, 422). Keep a consistent response envelope, page and filter with query params, and set ETag/Cache-Control so clients and CDNs can reuse responses.