The summary of REST
Architectural Styles and the Design of Network-based Software Architectures
A Brief Introduction to REST
Representational State Transfer (REST)
Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
REST Architectural Constrains
1. Client-Server
2. Stateless
communication must be stateless in nature.
3. Cache
the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.
4. 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.
constraints:identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
5. Layered System
to further improve behavior for Internet-scale requirements.
The combination of layered system and uniform interface constraints induces architectural properties similar to those of the uniform pipe-and-filter style.
6. Code-On-Demand
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
REST Architectural Elements
1. Data Elements
the nature and state of an architecture's data elements is a key aspect of REST: When a link is selected, information needs to be moved from the location where it is stored to the location where it will be used by. This is unlike many other distributed processing paradigms, to move the "processing agent" to the data rather than move the data to the processor.
Data Element Modern Web Examples
resource the intended conceptual target of a hypertext reference
resource identifier URL, URN
representation HTML document, JPEG image
representation metadata media type, last-modified time
resource metadata source link, alternates, vary
control data if-modified-since, cache-control
1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource.
The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another. Requests and responses have the appearance of a remote invocation style, but REST messages are targeted at a conceptual resource rather than an implementation identifier.
This abstract definition of a resource enables key features of the Web architecture: it provides generality; it allows late binding of the reference to a representation; it allows an author to reference the concept rather than some singular representation.
1.2 Representations
A representation is a sequence of bytes, plus representation metadata to describe those bytes.
Control data defines the purpose of a message between components, such as the action being requested or the meaning of a response.
The data format of a representation is known as a media type.
2. Connectors
Connector Modern Web Examples
client libwww, libwww-perl
server libwww, Apache API, NSAPI
cache browser cache, Akamai cache network
resolver bind (DNS lookup library)
tunnel SOCKS, SSL after HTTP CONNECT
3. Components
Component Modern Web Examples
origin server Apache httpd, Microsoft IIS
gateway Squid, CGI, Reverse Proxy
proxy CERN Proxy, Netscape Proxy, Gauntlet
user agent Netscape Navigator, Lynx, MOMspider
REST Architectural Views
1. Process View
REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries--proxies, gateways, and firewalls--to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.
2. Connector View
REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components.
Interaction with those services(FTP, Gopher, WAIS) is restricted to the semantics of a REST connector.
3. Data View
Component interactions occur in the form of dynamically sized messages. Small or medium-grain messages are used for control semantics, but the bulk of application work is accomplished via large-grain messages containing a complete resource representation. The most frequent form of request semantics is that of retrieving a representation of a resource (e.g., the "GET" method in HTTP).
An application's state is therefore defined by its pending requests, the topology of connected components, the active requests on those connectors, the data flow of representations in response to those requests, and the processing of those representations as they are received by the user agent.
An application reaches a steady-state whenever it has no outstanding requests. For a browser application, this state corresponds to a "web page"(received).
The next control state of an application resides in the representation of the first requested resource.
The application state is controlled and stored by the user agent.
REST style does not assume that all applications are browsers.
The notion of state: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
REST vs EBI: The key difference is that EBI(event-based integration) styles are push-based. In the REST style, consuming components usually pull representations.
REST vs C2: Both have clear notion of components, connectors, and representations. C2 is nominally push-based, though a C2 architecture could operate in REST's pull style by only emitting a notification upon receipt of a request. However, the C2 style lacks the intermediary-friendly constraints of REST, such as the generic resource interface, guaranteed stateless interactions, and intrinsic support for caching.
Experience and Evaluation
1. REST Applied to URI
URI<>URL. URL: a document's location on the network. REST define a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created.
a client is restricted to the manipulation of representations rather than directly accessing the implementation of a resource(manipulated to be representations of the identified resource, rather than the resource itself).
The resource is not the storage object. The resource is not a mechanism that the server uses to handle the storage object. The resource is a conceptual mapping(applies identifier to its current mapping implementation).
One form of abuse is to include information that identifies the current user within all of the URI; Another conflict with the resource interface of REST occurs when software attempts to treat the Web as a distributed file system.
2. REST Applied to HTTP
One weakness that still exists in HTTP is that there is no consistent mechanism for differentiating between authoritative responses, which are generated by the origin server in response to the current request, and non-authoritative responses that are obtained from an intermediary or cache without accessing the origin server.
Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application. The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser. Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics.
A Brief Introduction to REST
Representational State Transfer (REST)
Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
REST Architectural Constrains
1. Client-Server
2. Stateless
communication must be stateless in nature.
3. Cache
the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.
4. 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.
constraints:identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
5. Layered System
to further improve behavior for Internet-scale requirements.
The combination of layered system and uniform interface constraints induces architectural properties similar to those of the uniform pipe-and-filter style.
6. Code-On-Demand
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
REST Architectural Elements
1. Data Elements
the nature and state of an architecture's data elements is a key aspect of REST: When a link is selected, information needs to be moved from the location where it is stored to the location where it will be used by. This is unlike many other distributed processing paradigms, to move the "processing agent" to the data rather than move the data to the processor.
Data Element Modern Web Examples
resource the intended conceptual target of a hypertext reference
resource identifier URL, URN
representation HTML document, JPEG image
representation metadata media type, last-modified time
resource metadata source link, alternates, vary
control data if-modified-since, cache-control
1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource.
The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another. Requests and responses have the appearance of a remote invocation style, but REST messages are targeted at a conceptual resource rather than an implementation identifier.
This abstract definition of a resource enables key features of the Web architecture: it provides generality; it allows late binding of the reference to a representation; it allows an author to reference the concept rather than some singular representation.
1.2 Representations
A representation is a sequence of bytes, plus representation metadata to describe those bytes.
Control data defines the purpose of a message between components, such as the action being requested or the meaning of a response.
The data format of a representation is known as a media type.
2. Connectors
Connector Modern Web Examples
client libwww, libwww-perl
server libwww, Apache API, NSAPI
cache browser cache, Akamai cache network
resolver bind (DNS lookup library)
tunnel SOCKS, SSL after HTTP CONNECT
3. Components
Component Modern Web Examples
origin server Apache httpd, Microsoft IIS
gateway Squid, CGI, Reverse Proxy
proxy CERN Proxy, Netscape Proxy, Gauntlet
user agent Netscape Navigator, Lynx, MOMspider
REST Architectural Views
1. Process View
REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries--proxies, gateways, and firewalls--to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.
2. Connector View
REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components.
Interaction with those services(FTP, Gopher, WAIS) is restricted to the semantics of a REST connector.
3. Data View
Component interactions occur in the form of dynamically sized messages. Small or medium-grain messages are used for control semantics, but the bulk of application work is accomplished via large-grain messages containing a complete resource representation. The most frequent form of request semantics is that of retrieving a representation of a resource (e.g., the "GET" method in HTTP).
An application's state is therefore defined by its pending requests, the topology of connected components, the active requests on those connectors, the data flow of representations in response to those requests, and the processing of those representations as they are received by the user agent.
An application reaches a steady-state whenever it has no outstanding requests. For a browser application, this state corresponds to a "web page"(received).
The next control state of an application resides in the representation of the first requested resource.
The application state is controlled and stored by the user agent.
REST style does not assume that all applications are browsers.
The notion of state: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
REST vs EBI: The key difference is that EBI(event-based integration) styles are push-based. In the REST style, consuming components usually pull representations.
REST vs C2: Both have clear notion of components, connectors, and representations. C2 is nominally push-based, though a C2 architecture could operate in REST's pull style by only emitting a notification upon receipt of a request. However, the C2 style lacks the intermediary-friendly constraints of REST, such as the generic resource interface, guaranteed stateless interactions, and intrinsic support for caching.
Experience and Evaluation
1. REST Applied to URI
URI<>URL. URL: a document's location on the network. REST define a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created.
a client is restricted to the manipulation of representations rather than directly accessing the implementation of a resource(manipulated to be representations of the identified resource, rather than the resource itself).
The resource is not the storage object. The resource is not a mechanism that the server uses to handle the storage object. The resource is a conceptual mapping(applies identifier to its current mapping implementation).
One form of abuse is to include information that identifies the current user within all of the URI; Another conflict with the resource interface of REST occurs when software attempts to treat the Web as a distributed file system.
2. REST Applied to HTTP
One weakness that still exists in HTTP is that there is no consistent mechanism for differentiating between authoritative responses, which are generated by the origin server in response to the current request, and non-authoritative responses that are obtained from an intermediary or cache without accessing the origin server.
Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application. The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser. Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics.
