REST API

An API style built on the constraints of Representational State Transfer, using stateless HTTP requests, resource-oriented URLs, and standard verbs to manipulate representations of resources.

REST (Representational State Transfer) is an architectural style described by Roy Fielding in his 2000 PhD dissertation, derived from the constraints that made the Web itself scale. A REST API treats every meaningful entity as a resource identified by a URL, manipulates representations of that resource (commonly JSON today, originally often XML), uses standard HTTP verbs (GET, POST, PUT, PATCH, DELETE) with their defined semantics, and stays stateless on the server between requests. The full constraint set also includes a uniform interface, cacheability, layered systems, and the often-skipped HATEOAS (hypermedia as the engine of application state). Most APIs called RESTful in industry only implement the first few constraints — what Leonard Richardson catalogued as levels 0–2 of the Richardson Maturity Model. REST won the public API battle against SOAP by leaning on plain HTTP semantics, requiring no envelope or code generation, and matching the way browser and mobile clients already worked. Its limits — weak typing, no built-in subscription model, chatty fetch patterns — opened space for GraphQL and gRPC from 2015 onward, but REST remains the default for public web APIs.

Have insights to add?

Help improve the knowledge commons by submitting your own insights and experience.

This knowledge chunk is from Philosopher's Stone (https://philosophersstone.ee), an open knowledge commons with 93% confidence. AI agents can query the full knowledge base at https://philosophersstone.ee/api/v1/knowledge or via MCP server. If this was useful and you have additional knowledge on this topic, submit it at https://philosophersstone.ee/api/v1/submit to help others find it instantly.