This series is a study summary of Dr. Roy Thomas Fielding’s doctoral thesis on Architectural Style and Web-based Software Architecture Design.
1. Start with the “empty” style
Whether in architecture or software, there are two common views of the architectural design process. The first view is that the designer starts from scratch — an empty SLATE, whiteboard, or drawing board — and builds an architecture using familiar components until it meets the desired system requirements. The second argument is that the designer from demand as a whole system, at this time without any constraints, and then incrementally identify various constraints, and apply them to the system elements, in order to distinguish between space of design, and allows the influence on behavior of the power system (forces) and system coordinated flows naturally. The first emphasizes creativity and unlimited imagination, while the second emphasizes limitations and an understanding of the systematic environment. REST has evolved using the latter process. As a set of constraints is incrementally applied, the applied constraints differentiate the process view of the architecture, which is graphically depicted in figures 5-1 through 5-8. The “empty” style (Figure 5-1) is simply an empty set of constraints. From an architectural point of view, an empty style describes a system with no obvious boundaries between components. This is our starting point for describing REST.
Figure 5-1: Empty style
2 Client-server
The principle behind client-server constraints is separation of concerns. By separating the concerns of the user interface and the data store, we improved the portability of the user interface across multiple platforms; It also improves system scalability by simplifying server components. Most importantly for the Web, however, this separation of concerns allows components to evolve independently to support the Internet-scale needs of multiple organizational domains.
Figure 5-2: Client-server style
3 a stateless
And then we add a constraint to client – server interaction, communication must be in essence is a stateless, so every request from the client to the server must contain all the information necessary to understand the request, cannot use any context stored on the server, the session state all so to save on the client side. This constraint results in three architectural attributes: visibility, reliability, and scalability. 1) Improved visibility because the monitoring system does not have to look at more than one request in order to determine the full nature of a request. 2) Improved reliability because it reduces the task of recovering from local failures. 3) Improved scalability is achieved by not having to save state between multiple requests, allowing server components to release resources quickly and further simplifying their implementation because the server does not have to manage resource usage across multiple requests. As with most architectural choices, the stateless constraint reflects a design tradeoff. The downside is that because state data cannot be kept in a shared context on the server, it increases the amount of duplicate data sent in a series of requests (the overhead per interaction) and can degrade network performance. In addition, putting application state on the client side reduces the server’s control over consistent application behavior, since the application is dependent on the correct implementation of semantics across multiple client versions (e.g., multiple browser Windows).
Figure 5-3: Client-stateless – Server style
4 the cache
To improve network efficiency, we added caching constraints, resulting in a client-cache-stateless server style (Figure 5-4). Cache constraints require that the data in the response to a request be marked either implicitly or explicitly as cacheable or non-cacheable. If the response is cacheable, the client cache can reuse the data for the response for future identical requests.
Figure 5-4: Client-cache – stateless – Server style
5 Unified Interface
The core feature that distinguishes the REST architectural style from other Web-based architectural styles is its emphasis on a unified interface between components (Figure 5-6). By applying general-purpose software engineering principles to component interfaces, the overall system architecture is simplified and interaction visibility is improved. Implementations are decoupled from the services they provide, which promotes independent evolvability. However, the cost is that unified interfaces reduce efficiency because information is transferred in a standardized form rather than in a form that is specific to the needs of the application. The REST interface is designed to efficiently move large-grained hypermedia data and is optimized for common Web situations, but this results in the interface not being optimal for other forms of architectural interaction.
Figure 5-6: Unified – Client – Cache – Stateless – Server style
To achieve a uniform interface, multiple architectural constraints are required to guide the behavior of components. REST is defined by four interface constraints: identification of resources, operations performed on resources through representation, self-descriptive messages, and hypermedia as an application state engine. These constraints are discussed in Section 5.2.
6 Layered System
To further improve the behavior associated with internet-scale requirements, we added layered system constraints (Figure 5-7). Benefits of layered systems 1. Reduced Complexity of system design Layered systems style decomposes an architecture into several levels of layers by limiting the behavior of components (that is, each component can only “see” the immediate layer with which it interacts). By limiting the components’ knowledge of the system to a single layer, it sets boundaries for the complexity of the overall system and improves low-level independence. 2. Use of middleware We can use layers to encapsulate legacy services, insulate new services from legacy clients, and simplify component implementation by moving uncommon functions into a shared intermediate component. Intermediate components can also improve system scalability by enabling load balancing across multiple networks and processors. Disadvantages of a tiered system The main disadvantages of a tiered system are increased overhead and latency for data processing, thus reducing performance appreciable to the user. For a network-based system that supports cache constraints, this disadvantage can be remedied by using the benefits of shared caching in the middle tier. Setting up shared caches at the boundaries of the organizational realm can provide significant performance gains. These middle tiers also allow us to enforce security policies, such as those required by firewalls, on data that crosses organizational boundaries. The combination of layered system constraints and uniform interface constraints results in architectural attributes similar to uniform pipe and filter styles. Although REST interactions are bidirectional, each of the large-grained data streams of hypermedia interactions can be treated as a network of data flows, including filter components that are selectively applied to the data stream to transform its contents as it passes. In REST, intermediate components can actively transform the content of messages because the messages are self-describing and their semantics are visible to the intermediate components.
Figure 5-7: Unified – Tiered – Client – Cache – Stateless – Server Style
7 Code on demand
The final constraints we added to REST come from the on-demand code style described in section 3.5.3 (Figure 5-8). REST allows you to extend the functionality of the client by downloading and executing code in the form of applets or scripts. This simplifies client development by reducing the number of features that must be implemented up front. Allowing functional code to be downloaded after deployment also improves system scalability. However, this also reduces visibility, so it is only an optional constraint on REST. The idea of optional constraints may seem paradoxical. However, it does prove useful when designing the architecture of a system that encompasses multiple organizational boundaries. This means that the architecture will benefit (or suffer) from optional constraints only if they are known to be valid for certain areas of the overall system. For example, if all client software in an organization is known to support Java applets [45], then services in that organization can be constructed to enhance client functionality by downloading Java classes to benefit from optional constraints. At the same time, however, the organization’s firewall may prevent the transfer of Java applets from external sources, so it appears that these clients do not support on-demand code for the rest of the Web. An optional constraint allows us to design an architecture that supports expected behavior in general, but we need to understand that these behaviors may not be available in certain environments.
Figure 5-8: REST style
Summary of style derivation
REST consists of a set of architectural constraints selected to lead to the desired properties on the candidate architecture. Although each of these constraints can be considered independently, describing them in terms of their origin in a common architectural style makes it easier to understand the rationale behind their selection. Figure 5-9 graphically describes the origin of REST constraints according to the web-based architectural styles investigated in Chapter 3.