REST is an acronym and stands for REpresentational State Transfer. REST was first described by Roy Fielding in his PhD thesis, published in 2000. Over the years it has gained acceptance as a better and easier alternative to SOAP and WSDL (Web Service Description Language).
REST is neither a framework nor a technology.
“REST is an Architectural Style built on certain principles using the current HTTP web fundamentals”. The above definition can be put in the following simple diagram:
Figure 1: Simple diagram
Here we come across two words “Architectural style and Fundamentals”. Let’s see what they mean:
In the software world we have three terminologies which might confuse us they are: Architecture pattern, Architectural style and Design pattern. Following we have detailed the differences between the three:
- Architecture pattern: An Architectural Pattern is a way of solving a recurring architectural problem. MVC, for instance, solves the problem of separating the UI from the model. Sensor-Controller-Actuator is a pattern that will help you with the problem of actuating in face of several input senses.
- Architectural Style: An Architectural Style, on the other hand, is just a name given to a recurrent Architectural Design. Contrary to a Pattern, it doesn't exist to "solve" a problem. Client/server, Main program & subroutine and Abstract Data Types / OO, Service Oriented Architecture (SOA) does not solve a problem. They are just concepts or names given. Also, a single architecture can contain several architectural styles, and each architectural style can make use of several architectural patterns.
- Design Pattern: A design pattern is a solution at code level; it talks about classes, functions and logic of how the code flows.
Fundamentals are leveraged to create REST services. There are basically five fundamentals or principles:
- Resources: Application state and functionality are abstracted into resources.
- Unique Identifier: Every resource is uniquely addressable using a universal syntax for use in hypermedia links.
- Uniform Interfaces: All resources share a uniform interface for the transfer of state between client and resource.
- Representations: A representation captures the current or intended state of a resource.
- Stateless: REST recommends server not to save the state of each client request. All information needed for request to be handled should be included in request. Server does not need to save information related to client, so the system can respond flexibly to the increase of the number of clients.
We also need to understand a one more jargon called constraint which is often associated with REST. According to the REST thesis by Roy Fielding, a constraint is a rule that induces one or more software architecture properties. A group of constraints is called a style. The REST style is a group of six major constraints that induce the various properties needed for the Web. In order for architecture to be viewed as REST architecture, it must satisfy all of these constraints. They are:
- Stateless communication
- Uniform Interface
- Layered System
- Code On demand
Roy Fielding defines the non-functional property set that he uses to evaluate various architectural styles against one another:
Figure 2: Architectural Properties
A REST based system should exhibit the above architectural properties or goals. An explanation for these is as follows:
The term performance means different things to different people. To end users, high performance means that when they click on a link, or click on a buy button on an e-store, they get immediate results; to developers, it means solving the typical problem of service availability and supporting architectures that are scalable.
REST can support the Performance goal by using caches to keep available data close to where it is being processed. It can further help by minimizing overhead associated with setting up complex interactions by keeping each interaction simple and self-contained (as a request-response pair).
Scalability, in the context of the Web, means to consistently provide service regardless of the increase or decrease of web users.
REST-style architectures support load balancing across service instances via the Layered System and Uniform Interface constraints. This can be further simplified through the Stateless constraint, which structures interactions as request-response pairs that can each be handled by services independently of other requests. There is no need to keep directing the same service consumer to the same service instance or to synchronize session state explicitly between service instances; the session data is contained in each request.
By separating the functionality within components in a system, we can induce the simplicity to the architectural styles. If functionality can be allocated such that each component is less complex, then they will be easier to understand and implement.
The major contribution of REST to Simplicity is the Uniform Interface constraint. Overall system architecture is simplified and the visibility of interactions is improved. The functionality encapsulated by services is abstracted from the underlying interface implementation.
The requirements for any architecture are bound to change over time. Modifiability represents the ease at which changes can be incorporated in the architecture.
Modifiability in REST-style architecture is further broken down into the following areas:
- Evolvability - Represents the degree to which a component can be re-factored without impacting other parts of the architecture.
- Extensibility - The ability to add functionality to the architecture (even while solutions are running)
- Customizability - The ability to temporarily modify parts of a solution to perform special types of tasks
- Configurability - The ability to permanently modify parts of an architecture
- Reusability - The ability to add new solutions to architecture that reuse existing services, middleware, methods, and media types, without modification.
Modifiability is particularly important for larger distributed architectures where it is not possible to redeploy the entire environment every time an architectural improvement is made.
Visibility refers to the ability of a component to monitor or mediate the interaction between two components. REST supports visibility through Uniform Interface constraint. Visibility can enable:
- Improved performance via shared caching of interactions,
- Scalability through layered services,
- Reliability through reflective monitoring
- Security by allowing the interactions to be inspected by mediators
Portability represents the each with which a system can be moved from one deployed location to other.
In REST architecture style, the client/server constraint helps improve the UI portability.
Reliability of a distributed architecture is the degree to which its solutions and services (and underlying infrastructure) are susceptible to failure. An architecture style can improve the reliability by avoiding single points of failure, using failover mechanisms, and relying on monitoring features that can dynamically anticipate and responds to failure conditions.
Following diagram lists the tools used for development of REST architecture style:
Figure 3: Rest Tools
- uniform resources having identifiers increases reuse potential
Minimizes coupling to enable evolution
- uniform interface hides all implementation details supporting low coupling
- hypertext allows late-binding of application control-flow, hence leading to reduction in attempted inappropriate accesses and resultant errors.
- gradual and fragmented change across organizations
Eliminates partial failure conditions
- server failure does not perplex client state
- shared state is recoverable as a resource, leading to improved fault tolerance
Scales without bound
- services can be layered, clustered, and cached leading to improved scalability.
In this article we saw an introduction to REST architecture. Hope you liked it.