RESTful and Didn't Know It

I once worked for a large company and had to create a web application to display scanned images that would be used by hundreds of people. To improve performance, I carefully chose unique file paths that would increase the chances that the file would be cached by the web server and the user's web browser.

I was RESTful and didn't even know it.

In fact, when I recently asked a developer what REST was, he shrugged and said,"The Internet".

REST, or Representational State Transfer, is a terrible name for using HTTP effectively. Although REST doesn't necessarily have to apply to HTTP, it's clearly based on this protocol of the World Wide Web.

Most web developers, for example, don't think about using "GET" or "POST" in forms except whether or not it's convenient to place form variables on the URL. However, "GET" or "POST" have different meanings. For example, a GET is often cachable while a POST is not. Likewise directories are often created for the by the programmer for the purpose of breaking up his web pages, not for consideration of how directories in a URL convey meaning.

REST defines the web as a client-server, stateless message, caching support, layered network. It attempts to define a standard that makes the web a uniform, readable, logically searchable place...and, of course, to efficiently use browser and web server caching and proxies in the process. Wikipedia, REST). To accomplish this, REST has restrictions on when you can use an HTTP command, where to use document links and how the URL must be structured.

There are no rules for how a URL is structured, but to achieve the goals of REST a URL is usually structured in a way that each directory in the URL refers to a more detailed subitem of a document. For example, to get the health of a player named "fred" in a game called "World of Hack Slash", a RESTful URL might be "http://games/world_of_hack_slash/player/fred/health". This URL is readable, is structured from general (on the left) to detail (on the right). If "health" is omitted, the site should return a document on fred (such as his profile and links to other resources related to fred). If "fred" is omitted, it can return a list of all players. And so on. Such a URL is readable and understandable and, because the URL to fred's health is unique, it can be cached.

While REST is simple in concept, unobtrusive and can be implemented without special software (unlike CORBA or SOAP), there are some drawbacks:

• There's no easy way to confirm if your application conforms to REST or not. An application might use HTTP GET and POST only and still call itself RESTful
• Some types of interactions, like asynchronous operations (deferred operations that don't return a result immediately), are not supported under REST
• REST does not permit user sessions or browser cookies (because the client and the server cannot see each other's state).
• REST doesn't define a way to validate data, data types, missing data or other types of integrity checking.
• REST forces a simple hierarchy on URL's. Not all problems can be rewritten to fit in such a scheme.
• REST does not guarantee delivery. Using the game example, if a client were to POST to "http://games/world_of_hack_slash/player" an HTML FORM to create a new player, there is no guarantee that the player is created. And getting a list of all players to see whether or not the player was made may not be practical: what if the player information is not unique or the amount of data to search is very large?

  A workaround is to do a two-phase commit: the client uses an HTTP POST to reserve space for a new player and the server returns a confirmation with the players name. Then use HTTP PUT to send the player data. If the POST is interrupted (the socket fails), the client can send another request to reserve space for a new player while the server can periodically release any allocated but not initialized players. Since PUT is repeatable, if the connection is broken, the client can PUT more than once until it receives a confirmation of success. (Wikipedia, Two-phase Commit).

• Some web platform software does not conform to the REST guidelines.

Regardless of your views on REST, the concept is a reminder that developing a web site should be more than slapping some directories and files together. A web site should be understandable, searchable and caching should be used effectively. There's no reason why a SOAP solution could not also be a REST solution, since they are not mutually incompatible, and get better caching in the process.

A few months ago, I got a phone call from a recruiter. "Can you name 3 HTTP verbs for sending data to a server?" I had written applications that used the verbs, but I didn't have them memorized. When I couldn't answer, I was told I was not good enough to work for them--they were a REST shop. I chuckled. I had been using REST--or, at least, some of the founding principles for years before REST even existed as a term. I was RESTful and didn't know it. Neither did she. Maybe the recruitment process could benefit from some guidelines, too--especially with their interview questions (A Tale of Two Tests: Effective Interview Testing, Lone Coder).

August 22, 2010