REST
REST is an architectural style for networked applications, defined by constraints rather than by a specification: a uniform interface, statelessness, cacheability, and a client-server separation. In practice it means organising an API around resources identified by URLs, manipulated with HTTP methods whose semantics are already defined.
GET /stations/42 retrieves; DELETE /stations/42 removes; POST /stations creates. The method carries the verb, so the URL names a thing rather than an action.
Why using HTTP’s semantics pays
The discipline is not aesthetic. HTTP’s method semantics are contracts intermediaries act on.
GET is safe and cacheable, so proxies and browsers cache it and prefetchers call it speculatively. A GET with side effects will eventually be invoked by something that was not asking for those side effects, and the resulting bug is baffling. PUT and DELETE are idempotent, so a client that times out can retry safely — and a retry-unsafe operation behind an idempotent method produces duplicates under exactly the network conditions where retries happen.
Status codes carry the same weight: 404 for a missing resource, 401 versus 403 for missing versus insufficient credentials, 409 for a conflict. Returning 200 with an error in the body means every layer above believes it succeeded.
Most “REST” APIs are not REST
Fielding’s definition includes hypermedia — responses containing links describing available transitions, so a client discovers the API by following them rather than by having URL structure compiled in. Almost nothing does this.
What the industry calls REST is resource-oriented HTTP with JSON, which is a subset. Purists find this irritating; I do not think it matters much. The valuable parts — resource orientation, correct method semantics, meaningful status codes — are the parts that get adopted, and hypermedia solves a coupling problem most APIs do not have, at a cost in complexity they would notice.
Where it strains
Over-fetching and under-fetching are the real limits, and they are what GraphQL exists to address. A resource-shaped response returns what the endpoint’s designer chose, so a client needing three fields gets thirty, and a client needing related data makes several round trips.
For a well-understood data model with predictable access patterns this is a non-issue, and a generated typed client gives most of the safety benefit for a fraction of GraphQL’s machinery. When clients genuinely need to shape their own queries, the calculus changes — see the comparison.