REST (Representational State Transfer) is an architectural style for designing networked applications that use HTTP verbs to operate on resources identified by URLs, with stateless client-server communication.

What is REST? Definition, examples and how it works

REST, short for Representational State Transfer, is an architectural style introduced by Roy Fielding in his 2000 doctoral dissertation (Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures"). It defines a set of constraints for building scalable web services. The core idea is that every piece of content or functionality is a resource, identified by a URI (typically a URL). Clients interact with these resources using standard HTTP methods: GET to retrieve, POST to create, PUT or PATCH to update, and DELETE to remove.

A RESTful API must be stateless: each request from a client contains all the information the server needs to process it. The server does not store any client context between requests. Resources are represented in formats like JSON or XML, and the representation includes hypermedia links that guide the client to related actions (a principle called HATEOAS, though this is often relaxed in practice). Caching is explicitly supported through HTTP cache headers to improve performance. The uniform interface and layered system constraints allow intermediaries like proxies and load balancers to operate transparently.

REST is not a protocol or a standard; it is an architectural style. It contrasts with SOAP (which is protocol-heavy and operation-centric) and with RPC-style APIs (which focus on actions rather than resources). Most modern public web APIs, from GitHub to Stripe, claim to be RESTful, though many implement only a subset of the full constraints, especially HATEOAS. REST remains the dominant design pattern for HTTP APIs because of its simplicity, scalability, and alignment with the web's existing infrastructure.

Key facts

Defined by Roy Fielding in his 2000 PhD dissertation at UC Irvine.
Uses HTTP methods (GET, POST, PUT, DELETE, PATCH) to operate on resources.
Stateless: each request is independent and contains all needed context.
Resources are identified by URIs and returned in representations like JSON or XML.
HATEOAS (Hypermedia as the Engine of Application State) is a key but often omitted constraint.

How it works in practice

A RESTful API for a blog might expose a resource at /posts. A GET request to /posts returns a list of blog posts. A POST to /posts with a JSON body creates a new post. A GET to /posts/42 retrieves the post with ID 42. A PUT to /posts/42 replaces that post entirely. A DELETE to /posts/42 removes it. Each response includes links like "next" or "prev" for pagination, and links to related resources such as the author or comments.

Related terms

HTTP API JSON SOAP HATEOAS CRUD Web Service

References

More in Web Protocols

CORS

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that lets servers explicitly allow web pages from one origin to request resources from a different origin via HTTP response headers.

GraphQL

GraphQL is a query language and runtime for APIs that lets clients request exactly the data they need in a single round trip, reducing over-fetching and under-fetching.

gRPC

gRPC is a high-performance, open-source remote procedure call framework initially developed by Google. It uses HTTP/2 for transport, Protocol Buffers as its interface definition language and message serialization format, and supports bidirectional streaming.

HTTP

HTTP is a text-based request-response protocol that defines how web clients and servers exchange resources, forming the foundation of data communication on the World Wide Web.

HTTP Pipelining

HTTP Pipelining is a technique in HTTP/1.1 that sends multiple requests on a single connection without waiting for each response, now largely replaced by HTTP/2 multiplexing.

HTTP Status Code

A three-digit integer in an HTTP response that indicates the result of the server's attempt to process the request, grouped into five classes (1xx through 5xx).

HTTP/1.1

HTTP/1.1 is the persistent-connection version of the Hypertext Transfer Protocol, defined in RFC 2616 and updated by RFCs 7230-7235, enabling multiple requests and responses over a single TCP connection.

HTTP/2

HTTP/2 is a binary, multiplexed version of HTTP that reduces latency through header compression, stream prioritization, and server push, as defined in RFC 7540.

HTTP/3

HTTP/3 is the third major version of the Hypertext Transfer Protocol, which runs over QUIC instead of TCP to reduce latency, eliminate head-of-line blocking, and improve connection setup time.

HTTPS

HTTPS (HTTP Secure) is HTTP traffic encrypted inside a TLS session, protecting data confidentiality, integrity, and server authenticity between a client and a web server.