Michael Knopf

Principles

Proponents of REST argue that the Web's scalability and growth are a direct result of a few key design principles:

• Application state and functionality are abstracted 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 which is:
  • Client-server
  • Stateless
  • Cacheable
  • Layered

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.

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 (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, XML or JSON document of some kind, although it may be an image, plain text, or any other content.

Claimed benefits

Many 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:

• Provides improved response time and reduced server load due to its support for the caching of representations
• Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
• 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 and mechanisms which 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 representations
• 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
  • The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific "queries" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this "representation" of a path or entry point into an application state becomes highly portable.

One can argue that any sufficiently rich command line interface can be considered "ReSTful" ... in that a fully qualified command line and set of switches/options and arguments can access any accessible application state. A web URL with query string is effectively a sort of command line with arguments.

RESTful example: the World Wide Web

The 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 typesincluding 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:

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 replacement 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.

It is important to note that HTML links only produce "GET" HTTP requests. HTML forms allow "GET" and "POST" methods. The other HTTP methods mentioned here are not available in HTML 4.01 or XHTML 1.0. WebDAV makes use of other HTTP verbs in a web context.