REST is short for Representational State Transfer. I'd place that into the category of names that makes more sense once you understand what REST is, but isn't quite so helpful in terms of explaining it. REST is often heard in the context of web services. When it was suggested as a topic for me to write about it was described to me as a web service but doing "the query string thing" to pass it parameters. That's not really what it's about, though.

Verbs and nouns

Verbs are doing words. Examples in natural language are "pay", "drink" and "shock". In most programming paradigms, we spend a lot of time defining how to do things, by writing methods, subroutines or functions. These are our programming equivalent of verbs.

Nouns represent entities. Examples in natural language are "money", "beer" and "mother". Whenever we have data in our program and we somehow identify it (for example, by name binding or variable declaration), these are just like nouns in natural language.

So what does this have to do with REST? With REST, you have full control over how you define the nouns, but the verbs (that is, the operations available to perform on nouns) are constrained by the system and not extensible. You perform an operation by locating an entity by knowing its "name", then do one of the limited number of operations available on it. The focus is on the nouns or, you could say, on the data.

This is a contrast to a RPC (Remote Procedure Call) model, which is commonly implemented using SOAP or the simpler XML-RPC. There, you expose a range of methods or procedures that can be called and supply them with data to operate on. The focus here is on verbs - the operation that is being performed.

Representations

The "RE" part of REST is an abbreviation of the word "representational". In REST, we deal with representations of entities. The way we choose to represent an entity - called the content type - is specific to the type of entity involved. However, for a given system these content types are generally constrained to relatively few widely readable formats (for example, RSS, SVG, HTML and so forth). While applications of XML or SGML are the most common representations, you can use others.

URIs

The nouns in REST are actually URIs (Uniform Resource Identifiers). URIs encompass URNs (Uniform Resource Names) and the more familiar URLs (Uniform Resource Locators). A URN is a pure name; it gives us no information on how to locate the entity in question. An example would be a book's ISBN number; it lets you uniquely identify the book, but alone it doesn't enable you to find a copy of it. A URL, on the other hand, describes how to locate an entity. We most often see them on the web, when they tell us all we need to know in order to locate a file (the protocol to use, the name or IP address of the server its on and the path to it).

One resource can refer to another using its URI. For example, a category resource could return an XML document containing a list of URIs (which may also be URLs) representing the products in that category. Similarly, an RSS document contains URLs referencing the original documents that are represented in the feed.

State

Another key concept of REST is that it is stateless. That is, you make a request by specifying a noun (in the form of a URI) and a verb. The operation happens, you get a result back, and then the exchange between the client and the server is over. The server doesn't retain any specific information about the client, and the client doesn't retain any specific information about the server. The only information exchanged is that described by the noun.

REST and the Web

The world wide web can, to some degree, be seen as a RESTful system (that is, a system implemented on the principles of REST). We have resources (that is, data) identified by nouns - URLs. We are free to define the structure of these resources by building up directory structures. Then we have the HTTP protocol, which defines a limited set of verbs.

The verbs in HTTP are more often known as the method. If you have ever written a form tag, you will have seen them.

<form action="something.pl" method="POST">

There are a limited number of verbs we can use, though more than we commonly see. You'll probably only have written GET or POST as the method, and may be aware that there is also a HEAD method. However, HTTP does specify several more, including PUT and DELETE.

Unfortunately, most systems don't support anything other than GET, HEAD and POST. Instead, we tend to use POST to "tunnel" other operations. That is, to create or delete something, we send a POST request specifying that we wish to do this. Trouble is, the temptation is then there to implement all kinds of operations, not just a constrained set like the REST model calls for.

Generally, however, many web operations are RESTful. Generally, a GET operation will be, unless you pass parameters in the query string that request a given operation be performed other than just requesting the data in a particular way, in which case you're doing something more like RPC.

The web doesn't always live up to the stateless qualities of REST, however. Cookies are a form of state maintained by the client, and generally the cookie will be mapped to some session data on the server. Thus, if you are implementing a true REST model, you shouldn't be using HTTP cookies to maintain sessions. Authentication and authorization is still possible - you just have to pass credentials with each request rather than a session identifier. In fact, that's what HTTP basic authentication does.

Advantages and Disadvantages

So far it feels like REST places a lot of constraints on us. Is there anything to be gained? The answer is yes, and for some systems they are desirable properties.

• Since you have no state, you don't need to tie a particular server to a particular client. Thus any server can handle a client's request, which allows you to scale more easily.
• Since the set of verbs is constrained, there are far fewer compatibility issues arising from the server or client not supporting a given operation than if you took an RPC approach.
• Since the representations used in RESTful systems are usually things like XML, it's easy to add support for new fields without forcing all systems to know about them. For example, even the oldest browsers with no CSS support can still render a modern HTML document in a readable way.
• By using URIs, and in turn URLs, we can take advantage of existing infrastructure to do resource location.
• If we use HTTP, then we already have a limited but widespread client that can access the data too (web browsers), as well as caching infrastructure to aid performance.

However, REST is not suitable for every circumstance. In fact, it doesn't intend to be. Sometimes your set of operations on different entities won't fall at all neatly into a create/read/update/delete model, or you will need to maintain state between requests. You may have full control over the clients and servers and explicitly want to know when they aren't both aware of the same set of operations and the parameters required by those operations. In these cases, RPC is a likely to be a better bet.

REST is good when you have got widely distributed data and no centralized control over clients, servers and representations. This is very much the case with things like RSS feeds, where many people are publishing them and there are many different readers. If every reader had to support every single field in documents provided by servers, we'd be unable to evolve RSS without causing widespread breakage and forcing everyone to upgrade their readers.

Conclusion

REST provides us with an approach to client-server interaction. There are relatively few widely used examples of it to observe: the semi-RESTful web aside, two of most common are RSS (mentioned in this article) and WebDAV (not mentioned, but basically an extension of HTTP's methods to be expressive enough to provide services such as version control over). It's certainly not appropriate for all situations, but the constraints it lays down are very much worth keeping in mind when designing distributed architectures with little centralized control.

Further Reading

If you want to know a lot more about REST and the thinking behind it, probably the best place to turn is the PhD thesis that coined the term. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm