REST (Representational State Transfer) is an architectural style for designing networked applications, defined by Roy Fielding in his 2000 doctoral dissertation, that uses stateless, resource-oriented HTTP methods to enable communication between clients and servers.
REST organizes an API around resources — discrete entities identified by URLs. Clients interact with these resources using standard HTTP methods: GET to retrieve, POST to create, PUT to replace, PATCH to partially update, and DELETE to remove. Each request is self-contained — the server stores no client state between calls, which makes REST APIs inherently scalable and cacheable. Responses typically use 📝JSON, though the architecture is format-agnostic.
The six constraints that define REST are client-server separation, statelessness, cacheability, a uniform interface, layered system architecture, and optional code-on-demand. In practice, most APIs described as "RESTful" implement a pragmatic subset of these constraints rather than adhering strictly to Fielding's original formulation. The uniform interface constraint — that resources are identified by URIs, manipulated through representations, and described by self-descriptive messages — is what gives REST its practical power and developer ergonomics.
REST dominates web API design because it maps naturally onto HTTP, requires no additional protocol layers, and is trivially consumable by any client that speaks HTTP. Alternatives like GraphQL and gRPC solve specific problems (over-fetching and performance, respectively), but REST remains the default for most web services, including identity providers like 📝Okta that expose their management and authentication APIs as RESTful endpoints. 📝SSO flows frequently rely on REST APIs for token exchange and user provisioning.