Representational State Transfer
From Wikipedia, the free encyclopedia
Categories: Wikipedia articles needing copy edit from January 2007 | All articles needing copy edit | Software architecture | Web 2.0 neologisms
Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. 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. The terms have since come into widespread use in the networking community. REST strictly refers to a collection of network architecture principles which outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface which 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 HTTP and without interacting with the World Wide Web. 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. The difference between the uses of the term “REST” causes some confusion in technical discussions. Systems which follow Fielding’s REST principles are often referred to as “RESTful”.
PrinciplesREST's proponents argue that the Web's scalability and growth are a direct result of a few key design principles:
(Fielding 2000, §5.3.1) REST's central principle: resourcesAn 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 which is 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 or XML document of some kind, although it may be an image or any other content. Claimed benefitsMany of the statements below refer to REST in the specific context of Web Services, as opposed to SOAP. REST was originally defined in Fielding’s dissertation in the context of information and media access. Fielding did not originally contrast REST with RPC. Advocates claim that REST:
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 are the constraints it imposes on any 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 methods 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. RESTful example: the World Wide WebThe World Wide Web is the key example of a RESTful design. Much of it conforms to the 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 compared with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies:[2] The following table associates several common HTTP verbs with similar database operations, however the meaning of the HTTP verbs do not 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 update as needed.
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 modeled 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 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. 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 access any conversation other than the one it is immediately involved with. REST versus RPCThe statements below refer to REST in the context of Web Services, specifically as opposed to SOAP. Note that Fielding’s dissertation presents REST in the context of information and media access, not web services. It does not contrast REST to RPC (remote procedure call).
Image:Resttriangle.svg
REST Triangle of nouns, verbs, and content types.
A RESTful web application requires a different design approach from an RPC application. An RPC application is exposed as one or more network objects, each with an often unique set of functions which 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 which 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 with which clients can interact uniformly, and to provide hyperlinks between resources which 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. ExampleAn 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.removeUser('001')
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 which 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 RPCThe 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 which 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 which controls uniformity. Public implementationsIt 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:
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).[3] Implementation challengesThere are examples of website interfaces which 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. This is the Flickr case. 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 when /thing.php will serve a GET request with XML generated from a database. Most published patterns for updating entities use the POST method. Outside of the WebJust 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]:
References
|2007-09-18 |17 September 2007}}
|2007-09-18 |17 September 2007}}
|2007-09-18 |17 September 2007}}
Notes
See also
External links
Products
de:Representational State Transfer es:Representational State Transfer fr:Representational state transfer ko:REST ja:REST pt:REST sv:REST |
