Sunday, April 22, 2007

Representational State Transfer[REST]


http://en.wikipedia.org/wiki/Representational_State_TransferFrom Wikipedia, the free encyclopedia

Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term originated in a doctoral dissertation about the web written in 2000 by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community.

“ Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an 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. ”
— Dr. Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures

REST strictly refers to a collection of architectural principles (described below). The term is also often used in a loose sense to describe any simple interface that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict as well as overlap. It is possible to design any large software system in accordance with Fielding's REST architectural style without using the HTTP protocol and without interacting with the world wide web. It is also possible to design simple XML+HTTP interfaces that do not conform to REST principles, and instead follow a Remote Procedure Call (RPC) model. The two different uses of the term REST cause some confusion in technical discussions.

Systems that follow Fielding's REST principles are often referred to as RESTful; REST's most zealous advocates call themselves RESTafarians.

Contents
1 RESTful Example: The World Wide Web
2 Principles
3 REST's Central Principle: Resources
4 Claimed Benefits
5 REST versus RPC
5.1 Example
5.2 Uniform Interfaces in REST and RPC
6 Public implementations
7 Outside of the Web
8 References
9 See also
10 External links



RESTful Example: The World Wide Web
The Web is the key example of existing RESTful design. Much of it conforms or can be made to conform to REST principles. The Web consists of the HyperText Transfer Protocol (HTTP), content types including the HyperText Markup Language (HTML), and other Internet technologies such as the Domain Name Service (DNS).

HTML can include javascript and applets to support code-on-demand, and has implicit support for hyperlinks.

HTTP has a uniform interface for accessing resources which consists of URIs, methods, status codes, headers, and content distinguished by mime type.

The most important HTTP methods are PUT, GET, POST and DELETE. These are often compared with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies. An analogy can also be made to cut and paste: GET is analogous to READ or COPY, PUT to CREATE or PASTE OVER, POST to UPDATE or PASTE AFTER, and DELETE to DELETE or CUT. The CRUD verbs are designed to operate on atomic data within the context of a database transaction. REST is designed around the atomic transfer of more complex state, such as can be seen in paste of a structured document from one application to another.

HTTP separates the notions of a web server and a web browser. This allows the implementation of each to vary from the other based on the client/server principle. When used RESTfully, HTTP is Stateless. Each message contains all the information necessary to understand the request when combined with state at the resource. As a result, neither the client nor the server needs to remember any communication-state between messages. Any state retained by the server must be modelled as a resource.

The statelessness constraint can be violated in HTTP using cookies to maintain sessions. Fielding notes the risks of privacy leaks and security complications that often arise through the use of cookies, and the confusions and bugs that can result from interactions between cookies and the "back" button in a browser.

HTTP provides mechanisms to control caching, and permits a conversation between web browser and web cache to occur using the same mechanisms as between web browser and web server. No layer can "see" beyond the conversation it is immediately involved with.


Principles
REST's proponents argue that the Web enjoyed the scalability and growth that it has had as a direct result of a few key design principles:

Application state and functionality are divided into resources
Every resource is uniquely addressable using a universal syntax for use in hypermedia links
All resources share a uniform interface for the transfer of state between client and resource, consisting of
A constrained set of well-defined operations
A constrained set of content types, optionally supporting code-on-demand
A protocol that is:
Client/Server
Stateless
Cacheable
Layered
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.[citation needed]

—Roy Fielding


REST's Central Principle: Resources
An important concept in REST is the existence of resources (sources of specific information), each of which can be referred to using a global identifier (a URI). In order to manipulate these resources, components of the network (clients and servers) communicate via a standardized interface (e.g. HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource that is a circle may accept and return a representation that specifies a centre point and radius, formatted in SVG, but may also accept and return a representation that specifies any three distinct points along the curve as a comma-separated list.

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering", another constraint of REST and a common principle in many other parts of information and networking architecture). Thus an application can interact with a resource by knowing two things: the identifier of the resource, and the action required – it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML or XML document of some kind, although it may be an image or any other content.


Claimed Benefits
REST advocates claim that REST:

Provides improved response times and server loading characteristics due to support for caching
Improves server scalability by reducing the need to maintain communication state. This means that different servers can be used to handle initial and subsequent requests
Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
Depends less on vendor software than mechanisms that layer additional messaging frameworks on top of HTTP
Provides equivalent functionality when compared to alternative approaches to communication
Does not require a separate resource discovery mechanism, due to the use of hyperlinks in content
Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
The capability of document types such as HTML to evolve without breaking backwards- or forwards- compatibility, and
The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
REST detractors note the lack of tool support and the scarcity of truly RESTful applications deployed on the web of today. Some claim that REST is applicable to GET, but unproven for other state transfer operations such as PUT. Fielding points out in his thesis that the REST architecture was designed specifically for massive scale hypermedia distribution, and not as a one size fits all architectural style. Indeed what characterizes REST is the constraints that it imposes on a REST based system. POST is often considered the only necessary client-to-server state transfer operation, and is treated as a mechanism to tunnel arbitrary method invocations across HTTP.

Some REST systems have been deployed and gained tools support such as WebDAV which uses not only GET and POST, but also established HTTP headers like HEAD, DELETE, PUT as well as WebDAV-specific HTTP methods: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.

One common stumbling block in the dialog on Claimed Benefits is focusing too much on web browser support for REST. Gateways, caching servers, proxies, and other REST connectors are the critical components for system design and REST.


REST versus RPC
REST: Resources - Commands are defined in simple terms: resources to be retrieved, stored / get, set - difficult to do many joins

RPC: Commands - Commands are defined in methods with varying complexity: depending on "standard" - easier (?) to hide complex things behind a method

REST: Nouns - Exchanging resources and concepts

RPC: Verbs - Exchanging methods





REST Triangle of nouns, verbs, and content types.A RESTful web application requires a different design approach from an RPC (Remote procedure call) application. An RPC application is exposed as one or more network objects, each with an often unique set of functions that can be invoked. Before a client communicates with the application it must have knowledge of the object identity in order to locate it and must also have knowledge of the object type in order to communicate with it.

RESTful design constrains the aspects of a resource that define its interface (the verbs and content types). This leads to the definition of fewer types on the network than an RPC-based application but more resource identifiers (nouns). REST design seeks to define a set of resources that clients can interact with uniformly, and to provide hyperlinks between resources that clients can navigate without requiring knowledge of the whole resource set. Server-provided forms can also be used in a RESTful environment to describe how clients should construct a URL in order to navigate to a particular resource.


Example
An RPC application might define operations such as the following:

getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()
Client code to access this application may look something like this:

exampleAppObject = new ExampleApp("example.com:1234")
exampleAppObject.getUser()
With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following resources

http://example.com/users/
http://example.com/users/{user} (one for each user)
http://example.com/findUserForm
http://example.com/locations/
http://example.com/locations/{location} (one for each location)
http://example.com/findLocationForm
Client code to access this application may look something like this:

userResource = new Resource("http://example.com/users/001")
userResource.delete()
Each resource has its own identifier noun. Clients start at a single resource such as the user resource that represents themselves, and navigate to location resources and other user resources. Clients work with each resource through standard operations, such as GET to download a copy of the resource's representation, PUT to paste a changed copy over the top of the original, or DELETE to remove the data or state associated with the resource. POST is sometimes used interchangeably with PUT, but can also be seen as a "paste after" rather than a "paste over" request. POST is generally used for actions with side-effects, such as requesting the creation of a purchase order, or adding some data to a collection. Note how each object has its own URL and can easily be cached, copied, and bookmarked.


Uniform Interfaces in REST and RPC
The uniform interface allows clients to access data from a range of resources without special code to deal with each one, so long as it is actually uniform. The content returned from a user resource could be the globally standard and RESTful HTML, a less RESTful industry standard representation such as UserML, or an unRESTful application-specific data format. Which content is returned can be negotiated at request time. The content could even be a combination of these representations: HTML can be marked up with Microformats that have general or industry-specific appeal, and these microformats can be extended with application-specific information.

Uniform interfaces reduce the cost of client software by ensuring it is only written once, rather than once per application it has to deal with. Both REST and RPC designs may try to maximise the uniformity of the interface they expose by conforming to industry or global standards. In the RPC model these standards are primarily in the form of standard type definitions and standard choreography. In REST it is primarily the choice of standard content types and verbs that controls uniformity.


Public implementations
It is possible to claim an enormous number of RESTful applications on the Web (just about everything accessible through an HTTP GET request or updateable through HTTP POST). Taken more narrowly, in its sense as an alternative to both Web Services generally and the RPC style specifically, REST can be found in a number of places on the public Web:

The 'blogosphere' — the universe of weblogs — is mostly REST-based, since it involves downloading XML files (in RSS, or Atom format) that contain lists of links to other resources;
The Atom Publishing Protocol for publishing to blogs is considered the canonical RESTful protocol;
Ruby on Rails 1.2 offers a REST model.
Various websites and web applications offer REST developer interfaces to data.
The size of the last category is very small (i.e., those that offer the Atom Publishing Protocol plus a handful of others).

There are examples of website interfaces that label themselves 'REST', but are, in fact, using HTTP to tunnel function calls or which offer a 'POX/HTTP', (Plain Old XML over HTTP) endpoint. These interfaces do not intentionally respect REST's architectural constraints. Some have been called Accidentally RESTful, by a REST expert. The 'accident' of RESTfulness occurs primarily when standalone GETs are used, i.e. when navigating through many GETs in hypermedia style is not supported, and when those GETs simply retrieve data and do not change it.


Outside of the Web
Just as much of the web can be seen as RESTful or nearly-RESTful, a number of existing protocols and architectures have RESTful characteristics. Software that may interact with a number of different kinds of objects or devices can do so by virtue of a uniform, agreed interface. Many of these uniform interfaces follow document-oriented REST patterns rather than object-oriented patterns [should expand on and thus clarify this distinction]:

Modbus is a protocol that allows memory ranges within PLCs to be addressed. Ranges can be written and read effectively as PUT and GET operations.
Java Beans and other systems that perform property-based editing follow the PUT and GET model of the REST architectural style. Rather than write object-specific editor code, the code is written once and can interact with various object types. Resources in this model are defined by the combination of an object identifier and a property name.
Document-oriented SOA has several RESTful characteristics
Desktop cut and paste is closely related to REST principles. Cursor positions and highlighted selections in the source and target applications define application state or resources. They are operated on by the small set of verbs CUT, COPY and PASTE. Once cut or copied, data is retained in a number of forms so that, when pasted, the richest format understood by both applications is transferred.

References
Roy T. Fielding, Richard N. Taylor, "Principled design of the modern Web architecture", ACM Transactions on Internet Technology (TOIT), Volume 2, Issue 2 (May 2002), ACM Press, ISSN:1533-5399
Roy T. Fielding, "Architectural Styles and the Design of Network-based Software Architectures", PhD thesis, UC Irvine, 2000, html
M zur Muehlen, JV Nickerson, Keith D Swenson, "Developing Web Services Choreography Standards-The Case of REST vs. SOAP", Decision Support Systems. Vol. 40, no. 1, pp. 9-29. July 2005, ISSN:0167-9236 PDF
R. Khare, R.N. Taylor, "Extending the Representational State Transfer (REST) architectural style for decentralized systems", 26th International Conference on Software Engineering, 2004. ICSE 2004. Proceedings. 23-28 May 2004, ISSN: 0270-5257, ISBN 0-7695-2163-0
Jay M. Tenenbaum, Rohit Khare, "Business Services Networks: delivering the promises of B2B", Proceedings of the IEEE EEE05 international workshop on Business services networks, 2005,
Jonathan Robie, "An XQuery Servlet for RESTful Data Services", Proceedings of XML 2006, Boston, Massachusetts, December 2006. html
Paul Prescod, "Second Generation Web Services", O'Reilly's XML.com website, February 06, 2002, html
Ian Jacobs, Norman Walsh, eds. "Architecture of the World Wide Web, Volume One", W3C, html

See also
Plain Old XML
Web service
List of Web service markup languages
Service-oriented architecture
Web operating system
RSSBus

External links
RESTwiki: a short summary of REST
Belgian Java User Group video presentation on REST - The Better Web Services Model by Stefan Tilkov
rest-discuss Yahoo! Group
Paul Prescod's REST Resources
"What is SOA and REST Web services ..."
Constructing or Traversing URIs? This article discusses what the "hypermedia as engine of application state" constraint means.
Building Web Services the REST Way
How I explained REST to my wife...
The REST dialogues
Restlet - Lightweight REST framework for Java
TRYNT - Creative Commons style REST Service Library
REST Search Engine A specialized search engine based on Google Co-op platform
REST for the Rest of Us
MindTouch Dream REST-based distributed application framework developed for Mono/.NET
Mixed reaction to JSR-311
Retrieved from "http://en.wikipedia.org/wiki/Representational_State_Transfer"
Categories: Wikipedia articles needing copy edit from January 2007 | All articles needing copy edit | Wikipedia articles needing style editing | Software architecture

No comments :