What is a REST API?
A REST API is a way of exposing your application's data over HTTP by modeling everything as resources — a user, an order, an invoice — each addressed by a URL and manipulated with standard verbs like GET, POST, PUT, and DELETE. Requests are stateless and responses are cacheable, which is exactly why REST scales as gracefully as the web it was modeled on.
Where REST came from
Roy Fielding, one of the authors of the HTTP spec, coined "Representational State Transfer" in his 2000 dissertation. He was not inventing a product — he was describing the architectural constraints that already made the web work, then arguing that APIs should follow the same principles. REST became the default style for web APIs because it leans on infrastructure the internet already had: URLs, HTTP methods, status codes, and caches.
Resources, verbs, and status codes
In REST, nouns are resources and verbs are HTTP methods. GET /orders/42 reads order 42; POST /orders creates one; PUT /orders/42 replaces it; DELETE /orders/42 removes it. The server answers with a status code that means something specific — 200 OK, 201 Created, 404 Not Found, 409 Conflict, 429 when you hit rate limiting. Used well, the protocol carries most of the meaning.
The constraints that define it
REST is more than "JSON over HTTP." Its defining constraints include statelessness — every request carries everything needed to process it, so no session state is stored on the server between calls — a uniform interface, a client-server split, and cacheability. Because requests are stateless, you can put a fleet of identical servers behind a load balancer and route any request to any instance. That property is the quiet reason REST scales so well.
Idempotency and safe methods
REST distinguishes safe methods (GET, which should never change state) from idempotent ones (PUT and DELETE, where repeating the call has the same effect as making it once). POST is neither, which is why retrying a failed POST can create duplicates. Handling that correctly is the domain of idempotency keys — a discipline any payment or order API has to get right, since a dropped response should never turn into a double charge.
REST vs the alternatives
REST is not the only game in town. GraphQL lets clients fetch exactly the fields they need and shines when many clients want different slices of data; gRPC is faster for service-to-service traffic. But REST's simplicity, ubiquitous tooling, and free HTTP caching keep it the default for public, resource-oriented APIs. We compare the two head to head in our REST vs GraphQL explainer.
At QUANT LAB
Most APIs we build are REST, because most products are well served by clean resources, predictable verbs, and honest status codes. Our API development work pairs that with the things that separate a real API from a toy: consistent error shapes, versioning so you can evolve without breaking clients, an OpenAPI spec that doubles as documentation, authentication on every route, and idempotency where it counts. The protocol is simple; doing it well is the work.
Long-form deep-dives that use this term
All postsAdding AI Features to Your SaaS (2026)
Where AI helps, build-vs-API trade-offs, evals, guardrails, and shipping without torching margins.
Read postBuilding Multi-Tenant SaaS on Postgres RLS
Row-level security patterns for isolating tenant data without separate databases.
Read postCaching Strategies for SaaS (2026)
Cache layers from CDN to Redis, invalidation that works, stampede protection, and what never to cache.
Read post
Related terms
Designing a REST API?
We design clean, versioned, well-documented REST APIs that are secure and a pleasure to integrate. Book a 30-minute call.