REST Architectural Properties

1. Overview

In this post, we’ll learn the REST architectural properties and how they affect the REST Architectural Constraints.

2. REST Architectural Properties


2.1. Performance

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 the overhead associated with setting up complex interactions by keeping each interaction simple and self-contained (as a request-response pair).

2.2 Scalability

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.

2.3. Simplicity

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. The overall system architecture is simplified and the visibility of interactions is improved. The functionality encapsulated by services is abstracted from the underlying interface implementation.

2.4. Modifiability

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 refactored 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.

2.5. Visibility

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

2.6. Portability

Portability represents the each with which a system can be moved from one deployed location to other. portability of components by moving program code with the data; In REST architecture style, the client/server constraint helps improve the UI portability.

2.7. Reliability

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 be relying on monitoring features that can dynamically anticipate and responds to failure conditions.

3. Conclusion

In this post, we have seen what are REST architectural properties and how they directly affect to constraints of the REST architectural style.