Representational State Transfer

Representational State Transfer
Name	Representational State Transfer
Author	Roy Fielding
Year	2000
Type	Architectural style
Related	HTTP, URI, Web architecture

Representational State Transfer is an architectural style for distributed hypermedia systems introduced in the doctoral dissertation of Roy Fielding. It defines constraints and principles intended to guide scalable, performant networked applications such as web services and applications that interact with Hypertext Transfer Protocol, Uniform Resource Identifier, HTML, XML, JSON, and other web protocols and formats. REST influenced the design of major web platforms and standards including Apache HTTP Server, Nginx, Google, Amazon Web Services, Microsoft Azure, and many open source projects across the internet ecosystem.

History

The concept appeared in Roy Fielding's 2000 dissertation at the University of California, Irvine, referencing historical developments in the World Wide Web led by figures and organizations such as Tim Berners-Lee, CERN, Mosaic, Netscape Communications Corporation, Internet Engineering Task Force, and the development of HTTP/1.0 and HTTP/1.1 standards. Early web architecture debates involved implementations from Apache Software Foundation, Microsoft, Sun Microsystems, and protocol work by contributors associated with IETF HTTP Working Group, RFC 2616, and later revisions like RFC 7230. REST emerged alongside competing paradigms influenced by distributed computing research at institutions such as MIT, Stanford University, and companies like IBM and Oracle Corporation. Adoption accelerated with web services efforts by Amazon (company), eBay, Google, and integration platforms from Salesforce, shaping practical RESTful approaches in enterprise integration and cloud computing.

Principles and Constraints

REST specifies a set of architectural constraints intended to enable scalability, generality of interfaces, independent deployment, and intermediary components. Key constraints include client-server separation influenced by research at Xerox PARC, stateless interactions with echoes in Sun Microsystems distributed object models, cacheable responses discussed in IETF, and uniform interfaces that leverage URI and media types like MIME. Other constraints such as layered systems and code-on-demand relate to proposals from entities like W3C, IETF HTTPbis, and experiments by Google Summer of Code participants. These constraints interact with standards promulgated by World Wide Web Consortium working groups, influencing technologies used by enterprises like Facebook and Twitter.

Architectural Elements

Architectural elements in RESTful systems include resources identified by Uniform Resource Identifier, representations encoded as HTML, XML, JSON, or YAML, and standardized methods originally defined in HTTP including GET, POST, PUT, DELETE, and PATCH. Interaction patterns draw on concepts from Hypermedia research, hypertext systems developed at Xerox PARC, and media type registration practices managed by IANA. Components commonly used in deployments include web servers such as Apache HTTP Server and Nginx, application platforms like Node.js, Java EE, Spring Framework, Django (web framework), and middleware from vendors such as Red Hat and IBM WebSphere. Security and identity layers reference mechanisms developed by OAuth 2.0, OpenID Connect, Transport Layer Security, and guidance from National Institute of Standards and Technology.

HTTP and RESTful Web Services

RESTful web services commonly rely on HTTP/1.1, HTTP/2, and emerging HTTP/3 features to manage semantics, content negotiation, caching, and connection behavior. Practical implementations use methods and status codes standardized in RFC 7231 and related documents, while tooling and frameworks originate from communities around GitHub, Stack Overflow, Maven Central, and package registries such as npm and PyPI. Major cloud providers including Amazon Web Services, Microsoft Azure, and Google Cloud Platform offer managed gateways, load balancers, and API management that facilitate RESTful deployments. Observability and operations draw on systems built by Prometheus, Grafana Labs, ELK Stack, and practices promoted by The Twelve-Factor App community and DevOps adopters like Netflix.

Design Patterns and Best Practices

Design patterns for RESTful APIs include resource modeling, hypermedia-driven APIs (HATEOAS), pagination, filtering, versioning, idempotency, and error handling modeled after conventions used by GitHub API, Stripe (company), Twitter API, Facebook Graph API, and Google APIs. Best practices integrate security via OAuth 2.0 and OpenID Connect, rate limiting and quota strategies inspired by Amazon API Gateway, and documentation approaches leveraging OpenAPI Specification and tools like Swagger UI, Postman, and API Blueprint. Implementation advice is influenced by software engineering practices from Martin Fowler, Kent Beck, and organizations practicing continuous delivery such as ThoughtWorks and Atlassian.

Criticism and Alternatives

Criticism of REST includes arguments about overloading HTTP semantics, under-specification of hypermedia affordances, and practical departures by popular APIs from Fielding's original constraints; commentators from Tim Bray, Erik Wilde, and practitioners at Google and Facebook have debated these topics. Alternatives and complements include SOAP, GraphQL, gRPC, Apache Thrift, OData, and protocol approaches such as WebSockets and MQTT used by companies like Twitter, Spotify, Netflix, and Adobe Systems. Academic critiques and proposals come from research at MIT, Stanford University, UC Berkeley, and standards discussions within IETF and W3C communities.

Category:Web architecture