Principles and History of REST
– REST is a software architectural style that defines constraints for distributed hypermedia systems.
– REST emphasizes uniform interfaces, independent deployment of components, and loose coupling between client and server.
– REST was introduced and defined by Roy Fielding in 2000.
– The Web started to become widely used in 1993-1994, leading to the need for a formal Web architecture.
– Fielding, involved in creating primary Web standards, created the REST architectural style over the next six years.
Architectural Properties and Constraints of REST
– REST is designed for client-server applications and promotes loose coupling.
– REST provides a uniform addressing protocol, text-based transfer of information, and enables robustness, independent deployment, and large-grain data transfer.
– REST affects performance, scalability, simplicity, modifiability, visibility, portability, and reliability.
– REST defines six guiding constraints, including client-server architecture, statelessness, cacheability, uniform interface, layered system, and code on demand.
– These constraints improve various non-functional properties of REST.
Client-Server Architecture and Stateless Protocol
– Client-server architecture separates user interface and data storage concerns, improving portability and simplifying server components.
– Stateless protocol means no session information is retained by the server, improving scalability and allowing independent evolution of components.
– Relevant session data is sent by the client in each packet of information.
Cacheability and Layered System
– Clients and intermediaries can cache responses, improving scalability and performance.
– Cache can be stored in client machines, browser cache storage, or Content Delivery Networks (CDNs).
– Layered system allows clients to be unaware of intermediaries, enabling load balancing, shared caches, and separate security layers.
– Intermediary servers can call multiple other servers to generate a response.
Uniform Interface, Classification Models, and Applications of REST
– Uniform interface simplifies and decouples the architecture, allowing resource identification, manipulation, self-descriptive messages, and dynamic discovery of available resources.
– Classification models like Richardson Maturity Model and HTTP-based API classification assess adherence to REST design principles.
– RESTful APIs adhere to REST architectural constraints, use standards like HTTP, URI, JSON, and XML, and are widely used in web development.
– RESTful services are lightweight, easier to develop and maintain, have better performance, and are suitable for resource-oriented architectures.
– Semantic Web Services combine RESTful principles with semantic technologies, enabling automatic discovery, composition, and enhancing interoperability and integration of distributed systems.
– RESTful services are highly scalable, platform-independent, widely used in mobile app development, and the foundation of popular web APIs. They are suitable for building distributed systems and microservices architectures.
This article may be too technical for most readers to understand. (October 2020) |
REST (Representational state transfer) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave. The REST architectural style emphasises uniform interfaces, independent deployment of components, the scalability of interactions between them, and creating a layered architecture to promote caching to reduce user-perceived latency, enforce security, and encapsulate legacy systems.
REST has been employed throughout the software industry to create stateless, reliable Web-based applications. An application that adheres to the REST architectural constraints may be informally described as RESTful, although this term is more commonly associated with the design of HTTP-based APIs and what are widely considered best practices regarding the "verbs" (HTTP methods) a resource responds to while having little to do with REST as originally formulated—and is often even at odds with the concept.
