User:Etan Wexler/Representational State Transfer

From Wikipedia, the free encyclopedia

 Please help improve this section by expanding it.
Further information might be found on the talk page or at requests for expansion.

Representational State Transfer (REST) is a style of software architecture for hypermedia systems of global scale, systems like the World Wide Web.

Contents

[edit] Origins

Roy Fielding iteratively and collaboratively developed the ideas of Representational State Transfer beginning in 1994[1], culminating in his 2000 doctoral dissertation, “Architectural Styles and the Design of Network-based Software Architectures”.[2]. In the dissertation, Fielding coined the term “Representational State Transfer”, chose the abbreviation “REST”, and defined his coinage.

(motivations: chapters 4 and 6)

[edit] Terminology

software architecture 
...
architectural style 
...
principle 
...
architectural element 
...
architectural property 
...
datum 
...
data 
...
component 
...
connector 
...
distributed 
...
network-based 
...
Internet-scale 
...

[edit] Principles

Fielding refers to principles of software engineering.

[edit] Abstraction

Abstraction is the “hiding [of] some of the details of a system through encapsulation in order to better identify and sustain its properties”.[3]

[edit] Generality

[4] [5] [6]

[edit] Separation of concerns

[5] [7] [8]

[edit] Simplicity (principle)

[9]

[edit] Information hiding

[10]

[edit] Architectural elements

...

[edit] Components

...

[edit] User agent

...

[edit] Origin server

...

[edit] Proxy

...

[edit] Gateway

...

[edit] Connectors

...

[edit] Client

...

[edit] Server

...

[edit] Cache

...

[edit] Resolver

...

[edit] Tunnel

...

[edit] Data

...

[edit] Resource

...

[edit] Resource identifier

...

[edit] Representation

...

[edit] Representation metadata

...

[edit] Resource metadata

...

[edit] Control data

...


[edit] Architectural properties

...

[edit] Network performance

...


[edit] User-perceived performance

...


[edit] Network efficiency

...


[edit] Scalability

...


[edit] Simplicity

...


[edit] Evolvability

...


[edit] Extensibility

...


[edit] Customizability

...


[edit] Configurability

...


[edit] Reusability

...


[edit] Visibility

...


[edit] Portability

...


[edit] Reliability

...

[edit] Architectural constraints

A system which follows REST

  • has clients that initiate communication, sending request messages to servers, which respond with response messages;
  • maintains state of any given session on the client, not on the server;
  • communicates state in request messages at a level sufficient to let a server understand and correctly process the request messages;
  • provides caches which store response messages and from which the system delivers a response message to those request messages which are substantially similar to the request message that first prompted the response message;
  • identifies resources, which are things of any type, using resource identifiers, which are relatively small data of a single type;
  • manipulates resources through representations, which are the combination of a byte stream and metadata, where the metadata enable correct interpretation of the byte stream;
  • describes each message within that message;
  • encapsulates application state in hypermedia;
  • separates functionality into layers, each of which relies on an immediately underlying layer to provide certain services (the bottom layer relying on a layer outside the system), and each of which provides certain services to the immediately overlying layer;
  • allows program code in representations in response messages.

[edit] Advertised benefits

(constraints induce properties)

Fielding constructed REST to contend well with heterogeneous software, global scale, partial failure, administrative boundaries, trust boundaries, and the scope of human discourse.

[edit] World Wide Web

The World Wide Web (sic) is the most prominent example of an application whose architecture largely adheres to REST. Key technologies of the World Wide Web include Uniform Resource Identifiers (URIs) and version 1.1 of the Hypertext Transfer Protocol (HTTP/1.1).

(chapter 6: evaluating the WWW, applying REST)

[edit] REST outside the Web

 Please help improve this section by expanding it.
Further information might be found on the talk page or at requests for expansion.
This article does not cite any references or sources. (December 2006)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

Aside from the World Wide Web, certain architectures have characteristics of REST:

[edit] Popular usage of the name

 This article does not cite any references or sources. (December 2006)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

The name “REST” is, circa 2006, finding frequent use in a loose sense to describe some programmatic interfaces to portions of the World Wide Web that use Extensible Markup Language (XML), YAML, Javascript Object Notation (JSON), or plain text over the Hypertext Transfer Protocol (HTTP) without an intermediate messaging layer. This usage of the name “REST” serves to distinguish the interfaces from those interfaces which employ Simple Object Access Protocol (SOAP) or remote procedure call (RPC).

(RPC has no intermediate messaging layer: how does RPC differ from soi disant REST?)

[edit] Neologisms

 This article does not cite any references or sources. (December 2006)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

People have coined new words around REST. Systems that obey the REST constraints are RESTful (sic). Some of REST’s advocates call themselves “RESTafarians” (sic), the label being a pun on “Rastafarian”.

[edit] References

  1. ^ Fielding, Roy Thomas; Richard N. Taylor. Principled Design of the Modern Web Architecture. ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002, pages 115–150.
  2. ^ Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
  3. ^ 1.1 Run-time Abstraction
  4. ^ 1.4 Properties
  5. ^ a b 2.3.3 Simplicity
  6. ^ 5.1.5 Uniform Interface
  7. ^ 3.4.1 Client-Server (CS)
  8. ^ 5.1.2 Client-Server
  9. ^ 4.3 Approach
  10. ^ 6.2.2 Manipulating Shadows

[edit] External links