The Lone Coder Reflections for the Unsung Linux Saviours
by Ken O. Burtch
RESTful and Didn't Know It
"Everything Old is New Again"
-- Peter W. Allan,
All That Jazz
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
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
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
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?
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).