Representational State Transfer (REST) is a design approach that enables two computers to talk to each other, similar to technologies like RPC, CORBA, SOAP, and DCOM. The concept was defined by Roy Fielding in his PhD dissertation, describing REST as an "architectural style for distributed hypermedia systems".

Two key elements of REST are resources and representations. A resource is the web-based service, web page, or other entity that is described by a URI. The representation is the content that might be returned to the user agent when accessing a given resource, such as an XML or JSON document.

There are many qualities about REST that make it interesting as a technology, including the fact it is a client/server technology, the server maintains no client state, caching is used to improve performance, a uniform interface exists to access resources, it is a layered architecture, and it allows for "code on demand" (e.g., JavaScript) to make the whole system more dynamic. Each of these concepts is described in detail in Fielding's dissertation.

Fielding refers to hypermedia as the engine of application state. This concept refers to the fact that representations contain hyperlinks that the user can select in order to drive the application, whether it is merely browsing the web or conducting some kind of business. The server guides the user by providing links, but it is the client that that selects a link and thus progresses the application state in one way or another.

When interacting with a web service, a client may use any number of HTTP request methods. Some of those methods result in a change in the representation of a resource and some do not. There are two important keywords related to REST: safe and idempotent.

The word "safe" means that if a given HTTP method is invoked, the resource state on the server remains unchanged. A GET request, for example, should always be safe. The word "idempotent" means that, regardless of how many times a given method is invoked, the end result is the same. Again, a GET request should be idempotent. A POST request, on the other hand is might not be safe or idempotent. A PUT request might be idempotent, but is likely not safe.

Resources: Fielding's Dissertation, RESTful Web Services

See Also: Hypertext Transfer Protocol (HTTP), Extensible Markup Language (XML), JavaScript Object Notation (JSON)