Representational State Transfer (REST)

Core characteristics

REST is not a protocol or a standard but a design approach. Its intent is to separate concerns between client and server and to make the interaction model predictable. Several architectural constraints form the backbone of REST:

• Client–server: clear separation between user interface concerns and data storage or business logic.
• Stateless: each request from client to server must contain all information needed to understand and process it; the server does not store session state between requests.
• Cacheable: responses can be labeled as cacheable or non-cacheable to improve scalability and performance.
• Uniform interface: a consistent, resource-based interface that decouples clients from servers.
• Layered system: intermediaries such as proxies or gateways can be inserted without changing the interface.
• Code on demand (optional): servers may transfer executable code to clients to extend functionality.

Resources and representations

REST treats important pieces of information as resources identified by URIs. A resource can have multiple representations — for example, the same resource might be requested as JSON, XML, or HTML depending on the client’s needs. Clients request representations, and the server responds with the current state of that resource in the chosen format. The concept of HATEOAS (Hypermedia as the Engine of Application State) describes how responses can include links that guide clients to available actions or related resources.

Common methods and status semantics

When deployed over HTTP, RESTful services commonly use standard HTTP methods to express intended actions:

• GET — retrieve a representation of a resource (safe, read-only).
• POST — create a subordinate resource or trigger processing.
• PUT — replace a resource or create it at a known URI.
• PATCH — apply partial modifications to a resource.
• DELETE — remove a resource.

Responses rely on HTTP status codes to indicate outcome (for example, success, creation, not found, or server error), and on media type headers to specify the representation format.

History and evolution

REST emerged from academic work on the World Wide Web and was articulated as an architectural style around 2000. It has since shaped how web services are designed and consumed. Over time, many APIs have adopted REST principles to achieve loose coupling and scalability; others have combined REST ideas with additional patterns, and alternative approaches such as GraphQL or RPC-style APIs have also become common where different trade-offs are desired.

Uses, benefits and distinctions

RESTful design is widely used for public and private web APIs because it leverages existing web infrastructure and HTTP semantics. Benefits include simplicity, cacheability, and broad client compatibility. Limitations arise when strict statelessness or fixed resource boundaries make complex interactions cumbersome. REST is often compared with SOAP and other RPC approaches; its emphasis on resources, standard verbs, and lightweight representations distinguishes it from heavier, contract-driven protocols.

For further reading on the architectural concept and its application to the web, see the original description and general resources about architectural styles at architectural style references and materials on the World Wide Web at World Wide Web resources.