REST (Representational State Transfer) is an architectural style for web APIs that identifies resources by URL and expresses actions on them via HTTP methods.
It's a set of constraints rather than a specific protocol or framework, and following them well yields scalability, cacheability, and simplicity.
Core principles: (1) resource-oriented URLs: represent resources as nouns, not verbs (`/users/42`, not `/getUser?id=42`); (2) honor HTTP method semantics: read=GET (safe), create=POST, full replace=PUT (idempotent), partial update=PATCH, delete=DELETE (idempotent) — this contract lets caching, retries, and crawling behave safely; (3) statelessness: each request carries what it needs so the server needn't remember prior requests; (4) separation of representation: serve the same resource as JSON, XML, etc. via content negotiation.
Most real-world 'REST APIs' are pragmatic compromises that follow only part of strict REST. In particular, HATEOAS — which Roy Fielding emphasized (responses include links to next actions so clients navigate without hardcoding) — is rarely honored. Status codes are also part of REST design, so use success, client-error (4xx), and server-error (5xx) codes accurately. Alternatives include GraphQL (query exactly the data you need from one endpoint) and gRPC (high-performance binary RPC), each with different trade-offs.