Representational State Transfer

From Wikipedia, the free encyclopedia

  (Redirected from RESTful)
Jump to: navigation, search

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. As such, it is not just a method for building "web services". The terms "representational state transfer" and "REST" were introduced in 2000 in the doctoral dissertation of Roy Fielding,[1] one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification.

It is possible to design a software system in accordance with Fielding's REST architectural style without using HTTP and without interacting with the World Wide Web.[2] It is also possible to design simple XML+HTTP interfaces which do not conform to REST principles, and instead follow a model of remote procedure call.

Systems which follow REST principles are often referred to as "RESTful".

Contents

[edit] Principles

The Web's scalability and growth are a direct result of a few key design principles:

Fielding describes REST's effect on scalability thus:

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.[3]

[edit] REST's central principle: resources

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin 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 which represents a circle may accept and return a representation which specifies a center point and radius, formatted in SVG, but may also accept and return a representation which 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, XML or JSON document of some kind, although it may be an image, plain text, or any other content.

[edit] RESTful example: the World Wide Web

The World Wide Web is the key example of RESTful design. Much of it conforms 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 System (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 POST, GET, PUT and DELETE. These are often respectively associated with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies:[4]

The following table associates several common HTTP verbs with similar database operations, however the meaning of the HTTP verbs do not always correspond directly with a single database operation. For example, an HTTP PUT is used to set the value of a resource and may result in either a creation or replacement as needed.

HTTP CRUD
POST Create
GET Read
PUT Update, Create
DELETE Delete

The HTTP standard states that POST is intended to create "a new subordinate of the resource identified".[5] The PUT operation is intended to create a new resource "stored under the supplied Request-URI" based on the enclosed entity in the request and in the case that the supplied Request-URI exists, "the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server" (i.e. update the resource).[6]

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

HTML links only produce HTTP GET requests, and HTML forms allow GET and POST methods. The other HTTP methods mentioned above are not available in HTML 4.01 or XHTML 1.0.[7] WebDAV makes use of other HTTP verbs in a web context.

[edit] RESTful web services

A RESTful web service is a simple web service implemented using HTTP and the principles of REST. Such a web service can be thought about as a collection of resources. The definition of such a web service can be thought of as comprising three aspects:

  • The base URI for the web service such as http://example.com/resources/cars
  • The MIME type of the data supported by the web service. This is often JSON , XML or YAML but can be any other valid MIME type.
  • The set of operations supported by the web service using HTTP methods (e.g. POST, GET, PUT or DELETE).

Members of the collection are addressed using URIs of the form <collectionURI>/<ID> where the ID can be any unique identifier. For example, a RESTful web service representing a collection of cars for sale might use the car registration number as the ID so that a particular car might be represented in the collection as http://example.com/resources/cars/YXZ123.

The following table shows how the HTTP verbs are typically used to implement a web service.

RESTful Web Service HTTP methods
Resource GET PUT POST DELETE
Collection URI such as http://example.com/resources/cars/ List the members of the collection. For example list all the cars for sale. Not generally used. Meaning defined as 'replace the entire collection with another collection'. Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation. Not generally used. Meaning defined as 'delete the entire collection'.
Member URI such as http://example.com/resources/cars/YXZ123 Retrieve the addressed member of the collection Update the addressed member of the collection or create it with the specified ID. Not generally used. It would imply treating the addressed member as a collection in its own right and creating a new subordinate of it. Delete the addressed member of the collection.

[8]

Unlike SOAP-based web services, there is no "official" standard for RESTful web services, and there will probably never be, for example, a W3C recommendation for REST-based web services[9].

[edit] REST versus RPC

A RESTful web application requires a different design approach from a Remote Procedure Call (RPC) application.

[edit] Example

[edit] RPC (not REST)

An RPC application might define operations such as the following:

getUser()
addUser()
removeUser()
updateUser()
listUsers()

Client code to access this application may look something like this:

exampleAppObject = new ExampleApp('example.com:1234')
exampleAppObject.removeUser('001')

[edit] RESTful equivalent

With REST, on the other hand, the emphasis is on the resources and on HTTP; for example, a REST application might define the following resources

http://example.com/users/
http://example.com/users/{user} (one for each user - where {user} is the unique user id)

Client code to access this application may look something like this:

userResource = new Resource('http://example.com/users/001')
userResource.delete()

This may result in the following HTTP request being sent

DELETE /users/001 HTTP/1.1
Host: example.com

[edit] URIs and the HTTP 'methods': nouns and verbs

Each resource has its own identifier URI. A client may start by sending a GET request to the collection URI, http://example.com/users/. It would receive a list of all users, including their individual IDs or URIs. From this, the client can identify a single resource such as the one that represents themselves and, by sending a PUT request to that specific URI, may update it. 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. A POST to a collection URI, such as http://example.com/users/, with valid data will insert a new user, which will then appear in the listing and may be inspected by ID with a further GET. On an online sales system, a POST to the relevant collection URI may request the creation of a new purchase order.[10]

[edit] Caching and the HTTP request headers

Each resource has its own unique URI and so can be cached, copied, and bookmarked. Within a fully specified REST system, the standard HTTP request headers as defined in RFC 2616 such as If-Match, If-Modified-Since etc. should all work in the ways described in the RFC document.[11][12]

[edit] 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 createable through HTTP POST). Taken more narrowly, in its sense as an alternative to the RPC style of Web Services, REST can be found in a number of places on the public Web:

Note that WSDL version 2.0 now offers support for binding to all the HTTP request methods (not only GET and POST as in version 1.1).[13]

[edit] False or weak forms

Some interfaces referred to as being "RESTful" do not intentionally respect REST's architectural constraints. REST advocate Mark Baker uses the term "accidentally RESTful"[14] to describe interfaces that partially follow REST's architectural constraints. For example, Flickr's interface can be considered RESTful in its use of standalone GET operations, but it does not attempt to support the full range of a REST interface.

[edit] Implementation

Implementation is hampered by limited support for HTTP PUT and DELETE in popular development platforms. For example, in the LAMP platform, support for PUT must be added as a module. Web searches offer few examples of how to implement updating database-driven content using PUT. For example, it is nontrivial to create a PHP script to update http://example.com/thing/1 with a PUT message and to hide implementation-specific script types such as /thing.php in public URIs. Many published patterns for updating and deleting entities use the POST method, which cuts across the RFC 2616 definition and therefore also across a key REST principle.

On the other hand, the Ruby on Rails framework can create RESTful architectures very directly.[15]

[edit] 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 which 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]:

[edit] Modbus

Modbus is a protocol which allows memory ranges within PLCs to be addressed. Ranges can be written and read effectively as PUT and GET operations.

[edit] JavaBeans

JavaBeans and other systems which 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.

[edit] SNMP

The SNMP protocol and its object model, which predate the Web, share some characteristics with RESTful systems. A strict verb discipline follows from the protocol's small operator set, and the 'resources' are addressed with a uniform global scheme of Object Identifiers. Most interaction occurs in client-server fashion, and the clients and servers (called managers and agents respectively) can be deployed and evolved independently. Each request-response pair can be understood in isolation.

However, movement through the space of Object identifiers is not assisted by hyperlinks, nor is it considered as traversal through states in a state machine. Rather, the manager uses prior knowledge of the Management Information Bases supported by this particular agent to request or change the information it is interested in. SNMP is focused on providing data about known elements of a device or entity in a LAN or limited-access WAN scope, rather than issues of Internet scaling and links between independently authored content.

[edit] CMIP

The CMIP protocol was designed to allow the control of network resources by presenting their manageable characteristics as object graphs. The objects have parent-child relationships which are identified using distinguished names and attributes which are read and modified by a set of CRUD operations. The notable non-restful aspect of CMIP is the M_ACTION operation although wherever possible, MIB designers would typically endeavour to represent controllable and stateful aspects of network equipment through attributes.

[edit] Footnotes

  1. ^ Chapter 5 of Fielding's dissertation is "Representational State Transfer (REST)".
  2. ^ A tutorial on implementing a REST architecture in pure Java (no HTTP or WWW involved) is available at http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=656910USCA&l=ARESTfulCorePart3&asrc=EM_NLN_4355675&uid=2625488
  3. ^ (Fielding 2000, §5.3.1)
  4. ^ IETF RFC 2616 "Hypertext Transfer Protocol – HTTP/1.1", R. Fielding et al., June 1999
  5. ^ "RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1". RFC. http://tools.ietf.org/html/rfc2616#page-54. Retrieved on 2009-01-29. 
  6. ^ "RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1". RFC. http://tools.ietf.org/html/rfc2616#page-55. Retrieved on 2009-01-29. 
  7. ^ "HTML 4.01 Specification: Forms in HTML Documents: The Form Element". W3C. http://www.w3.org/TR/html401/interact/forms.html#h-17.3. Retrieved on 2008-03-23. 
  8. ^ Richardson, Leonard; Ruby, Sam (2007), RESTful Web Services, O'Reilly (published (May 8, 2007)), ISBN 0596529260 
  9. ^ Elkstein, M. What is REST?. Retrieved on 2009-07-04.
  10. ^ Costello, Roger L.. "Building Web Services the REST Way". http://www.xfront.com/REST-Web-Services.html. Retrieved on 2009-06-20. 
  11. ^ "GET Object". Amazon Simple Storage Service: Developer Guide. Amazon Web Services. 2006-03-01. http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTObjectGET.html. Retrieved on 2009-06-27. 
  12. ^ "HttpMethods". RestWiki. FrontPage. December 31, 2005. http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpMethods. Retrieved on 2009-06-27. 
  13. ^ "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts". http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/#_http_binding_default_rule_method. 
  14. ^ accidentally RESTful
  15. ^ Miller, James; et al. "Getting Started with Rails". Rails Guides. rubyonrails.org. http://guides.rubyonrails.org/getting_started.html#rest. Retrieved on 2009-07-01. "Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities and browser quirks." 

[edit] References

[edit] External links

 This article's external links may not follow Wikipedia's content policies or guidelines. Please improve this article by removing excessive or inappropriate external links. (July 2009)
v • d • e
Internet search
Types
Tools
Applications
Protocols and standards
See also
Retrieved from "http://en.wikipedia.org/wiki/Representational_State_Transfer"
Personal tools