Selasa, 12 November 2013
Following is a description for REST along with flowcharts and graphics free to use under the CC-BY-SA 3 licence. REST or Representational State Transfer has seen frequent adoption in recent years through a combination of increased web appliances, increased internet user numbers, increased Cloud services and an overall faster hypermedia system (in R.Fielding lingo). Behind each of these factors are themselves a plethora of factors. One undeniable truth however is that REST is very easy to grasp and implement, regardless of a developer's technical background.
Specifically:
REST is at least comprised of a client-server architecture, requiring a tunnel and resolver (e.g. DNS lookup) and an optional cache, termed as connector-types. The REST author Roy Fielding, lays out sequential interaction constraints leading to a Uniform-Client-Cache-Stateless-Server architecture (Fig 1). REST information flow is inherently redundant, as "all information necessary for a connector to understand the request" is contained within each invocation, rendering REST interaction stateless. The client keeps all session state.
The stateless communication allows [1]:
As summarized in Chapter 5 of the REST description in Fielding's disseration:
REST or Representational State Transfer is a simple stateless architecture for distributed hypermedia systems, ignoring details of component and protocol implementation, and only mandates using the basic 'architectural style' of HTTP or the Hypertext Transfer Protocol.
Specifically:
REST is at least comprised of a client-server architecture, requiring a tunnel and resolver (e.g. DNS lookup) and an optional cache, termed as connector-types. The REST author Roy Fielding, lays out sequential interaction constraints leading to a Uniform-Client-Cache-Stateless-Server architecture (Fig 1). REST information flow is inherently redundant, as "all information necessary for a connector to understand the request" is contained within each invocation, rendering REST interaction stateless. The client keeps all session state.
 |
| Fig 1: Uniform-Layered-Client-Cache-Stateless-Server as shown and described in the R.Fielding Thesis Chapter 5 [1] |
The stateless communication allows [1]:
- removing the connectors need to retain application state between requests, thus
- thus reducing consumption of physical resources and
- improving scalability
- interactions to be processed in parallel
- without requiring that the processing mechanism understand the interaction semantics
- an intermediary to view and understand a request in isolation
- This may be necessary when services are dynamically rearranged
- simpler caching implementation
- by forcing all of the information that might factor into the reusability of a cached response to be present in each request
As summarized in Chapter 5 of the REST description in Fielding's disseration:
REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.
Please help and correct me to make this definition as sound as possible. You can download the entire dissertation by Roy Fielding here (pdf) or browse it online.
Sources: [1] Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000
Note: I will put up all current and future illustrations herein as svg, and graphml in this github repository. To correct the graphics, fork and edit them accordingly, so that other's can include the most up-to-date graphics of the master repository.
Sources: [1] Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000
Note: I will put up all current and future illustrations herein as svg, and graphml in this github repository. To correct the graphics, fork and edit them accordingly, so that other's can include the most up-to-date graphics of the master repository.