Representational State Transfer

Representational State Transfer
Name	Representational State Transfer
Developer	Roy Fielding
Influenced by	Hypertext Transfer Protocol, Hypertext Markup Language
Influenced	Web API, Cloud computing

Representational State Transfer. It is an architectural style for distributed hypermedia systems, first defined in a 2000 doctoral dissertation by computer scientist Roy Fielding. The style provides a set of constraints for designing networked applications, emphasizing scalability, simplicity, and a uniform interface between components. Its principles have become foundational for the design of modern web APIs and services on the World Wide Web.

Overview

The concept was formally introduced in Chapter 5 of Fielding's dissertation, "Architectural Styles and the Design of Network-based Software Architectures," which analyzed the World Wide Web's architecture. It describes how a client-server system should behave to achieve desirable properties like performance and modifiability. The style is directly derived from the design principles of the Hypertext Transfer Protocol and Uniform Resource Identifier specifications, which were co-authored by Fielding. Its adoption was accelerated by the need for a simpler alternative to complex protocols like SOAP and technologies associated with Web Services Description Language.

Architectural constraints

The architectural style is defined by six guiding constraints that a system must adhere to. The **client-server** constraint separates user interface concerns from data storage concerns, improving portability. A **stateless** constraint requires that each request from a client contain all the information needed for the server to understand it, improving reliability and visibility. The **cacheable** constraint dictates that responses must be implicitly or explicitly labeled as cacheable or non-cacheable, improving efficiency. A **uniform interface** simplifies the overall system architecture and is fundamental to the style's design. The **layered system** constraint allows an architecture to be composed of hierarchical layers, restricting component knowledge to a single layer. The optional **code-on-demand** constraint allows clients to download and execute code, extending client functionality.

Design principles

Key design principles emerge from the uniform interface constraint, which includes several sub-constraints. **Resource identification** dictates that individual resources, such as a document or image, are identified in requests using URIs. **Resource manipulation through representations** means that when a client holds a representation of a resource, it has enough information to modify or delete that resource on the server. **Self-descriptive messages** ensure each message contains sufficient information to describe how to process it, often using media types. **Hypermedia as the engine of application state** is a core principle where clients make state transitions only through actions identified within hypermedia, such as links provided by the server, a concept central to the World Wide Web.

Relationship to HTTP

The style is intrinsically linked to Hypertext Transfer Protocol, as HTTP/1.1 was a primary reference model for its constraints. Standard HTTP methods like GET, POST, PUT, PATCH, and DELETE map directly to the uniform interface operations for manipulating resources. HTTP status codes, such as 200 OK, 404 Not Found, and 500 Internal Server Error, are used to indicate the result of operations. The use of Hypertext Transfer Protocol Secure is standard for secure communication. While the style can be used over other protocols, its design is optimized for and most commonly implemented using the Internet Engineering Task Force's HTTP standards.

RESTful web services

A web service that conforms to the architectural constraints is commonly described as RESTful. These services provide interoperability between computer systems on the Internet and are a cornerstone of modern Cloud computing and Microservices architectures. Major technology companies like Google, Amazon, and Microsoft provide extensive RESTful APIs for their platforms. Frameworks such as Spring Framework, Ruby on Rails, and Django include built-in support for building these services. The OpenAPI Specification has become a standard for describing and documenting such APIs, promoting tools from vendors like Swagger and Postman.

Criticisms and limitations

Critics argue that the architectural style's constraints, particularly statelessness, can lead to performance overhead due to repeated authentication data transmission. The principle of **hypermedia as the engine of application state** is often ignored in practice, leading to what Fielding has criticized as "SOAP-RPC" style APIs that do not fully leverage the web's architecture. The lack of a built-in standard for API versioning or complex transaction support can lead to ad-hoc solutions. Furthermore, its reliance on HTTP can expose it to web-based security vulnerabilities documented by the Open Web Application Security Project. Alternatives like GraphQL, developed by Facebook, and gRPC, originally created by Google, have emerged to address perceived shortcomings for specific use cases like complex data fetching or high-performance internal communication.

Category:Web development Category:Application programming interfaces Category:Software architecture