RESTRepresentational State Transfer
An architectural style for web APIs that models resources as URLs and uses HTTP verbs (GET, POST, PUT, DELETE) to act on them.
· Reviewed by senior engineers
REST (Representational State Transfer) is the architectural style that dominates public web APIs. Resources — products, orders, users — are identified by URLs, and HTTP verbs describe what you want to do with them: GET to read, POST to create, PUT/PATCH to update, DELETE to remove. Responses are stateless, cacheable and usually JSON.
REST won because it maps cleanly onto how the web already worked. Any HTTP client speaks it, CDNs can cache GETs without understanding the payload, and engineers can reason about a system by reading its URL structure. It remains the right default for public APIs, partner integrations and most internal services that don't need the round-trip savings of GraphQL.
The failure mode of REST is endpoint sprawl: every new screen wants a slightly different payload, so the API grows /products, /products-with-stock, /products-summary until nobody can find the canonical one. The fix is disciplined design — sparse fieldsets, expansion parameters, and saying no to one-off endpoints — not abandoning REST.
We use REST for the majority of API work at devinsta: headless commerce backends, mobile app services, integrations with ERPs and CRMs. Where the client genuinely needs to compose data across many resources in one round-trip, we reach for GraphQL instead, but we make that choice deliberately rather than by fashion.