Representational State Transfer (REST)
5.1 Deriving REST
5.1.1 Starting with the Null Style
Two common perspectives on the process of architectural design:
The first is that a designer starts with nothing—a blank slate, whiteboard, or drawing board—and builds-up an architecture from familiar components until it satisfies the needs of the intended system.
The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system.
REST is based on the latter process.
The following eight sections depict how the applied constraints would differentiate the process view of an architecture as the incremental set of constraints is applied.
From the Null style (Figure 5-1) is simply an empty set of constraints. It is the starting point for our description of REST.
5.1.2 Client-Server
From the client-server architectural style (Figure 5-2)
Separation of concerns is the principle behind the client-server constraints. Perhaps most significant to the Web is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
5.1.3 Stateless
From the client-stateless-server (CSS) style (Figure 5-3)
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
Session state is kept entirely on the client.
Advantage: ease the pressure of Sever.
Disadvantage: decrease network performance by increasing the repetitive data in a series of requests in clients.
5.1.4 Cache
From the client-cache-stateless-server style (Figure 5-4).
Requiring: a response is implicitly or explicitly labeled as cacheable or noncacheable.
Advantage: eliminate some interactions.
Disadvantage: decrease reliability if state data within the cache differs significantly from the data that would have been sent directly to the server.
5.1.5 Uniform Interface
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6).
The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web.
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
5.1.6 Layered System
From layered system constraints (Figure 5-7).
The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
5.1.7 Code-On-Demand
From the code-on-demand style (Figure 5-8).
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
5.1.8 Style Derivation Summary
Figure 5-9 depicts the derivation of REST’s constraints graphically in terms of the network-based architectural styles examined in Chapter 3.
5.2 REST Architectural Elements
5.2.1 Data Elements
The nature and state of an architecture’s data elements is a key aspect of REST.
Three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
5.2.2 Connectors
5.2.3 Components
代理和網關之間的區別是，何時使用代理是由客戶端來決定的
5.3 REST Architectural Views
5.3.1 Process View
5.3.2 Connector View
5.3.3 Data View