REST

REST (Representational State Transfer) is an architectural style, defined by Roy Fielding in his 2000 dissertation, for designing networked applications on top of the web’s own foundations. Rather than a protocol or a specification, it is a set of constraints — stateless communication, a uniform interface, resources identified by URLs, and standard HTTP methods like GET, POST, PUT, and DELETE — that, followed together, produce systems that are scalable, cacheable, and loosely coupled. Its fit with how the web already works is why REST became the default way to build APIs.

• Resources and URLs - Everything is modeled as a resource with a stable address, and you act on it through representations rather than remote procedure calls.
• Uniform interface - A small, predictable set of HTTP methods and status codes means clients and servers can evolve independently.
• Statelessness - Each request carries everything needed to process it, which is what lets REST APIs scale horizontally behind load balancers and caches.
• Hypermedia (HATEOAS) - In its fullest form, responses link to related actions and resources, though most working APIs adopt REST pragmatically rather than purely.

In practice, REST is the lingua franca of the API economy — the style most public APIs describe with OpenAPI and the one most developers reach for first. Its conventions are so widely shared that tooling, gateways, documentation, and now AI agents can consume a “RESTful” API with reasonable expectations before reading a line of docs. I have long argued that REST is messier in the wild than the textbooks suggest, and that it lives alongside GraphQL, gRPC, and event-driven patterns rather than above them — but as a shared baseline for designing and governing web APIs, it remains the center of gravity.