There’s been a good amount of buzz surrounding web services for a some time now.  Built upon the same HTTP protocol we humans use every day when updating our Facebook profiles or Netflix queues, essentially web services involve requests for XML files made programmatically by applications.

Historically, the SOAP protocol has been used to implement the majority of web services.  Since web (HTTP) traffic flows freely through most firewalls on port 80, these services are relatively easy to deploy in terms of networking.  Implementation and maintenance, though?  Not so much.  This is because for each and every SOAP web service, the methods (the ‘verbs’ the service provider offers) have had to have been individually implemented and then fully described to the client machine ahead of time.  In some cases, this level of flexibility is useful and well worth the extra overhead - however, for many (if not most) web services, writing these methods each and every time represents a significant amount of ‘wheel reinventing’ and additional development time.

Luckily, it turns out that often the plumbing already built into the underlying HTTP protocol also contains all the method (verb) functionality needed for many web services as well.

And thus we come to the concept of RESTful web service design.

REST stands for “Representational State Transfer”, the latest trend in web service design.  Unlike SOAP, it’s more of an architecture philosophy than a protocol (since one REST’s key stipulations is that a client can only be either transitioning between states via interaction with the server or at ‘rest’, the acronym - like any good acronym - is a bit of a pun).

A few more characteristics of RESTful design:

• The server maintains no knowledge of the state of the client between the requests for data that allow it to change states.
• Unlike SOAP, REST is based upon a ‘representation’ of a resource/service rather than the resource/service itself.  That ‘representation’  is a URI (i.e. a human-readable domain/location name, much like you’d type into a browser).
• The methods (or verbs) are limited to what’s already built into HTTP.

Sound familiar?  It should – because since first being described by computer scientist and key HTTP architect Roy Fielding back in 2000, REST has became the key architectural principle behind the world wide web as we know it.  It’s only recently that it’s also come into prominence as a design principle behind the web services used by our computers as well.

And why is any of this cool?  RESTful web service design leverages the HTTP methods originally meant for use by humans for machines as well.  Along with the Semantic Web (another cool thing), the trend is clear: computers are starting to use the web more like we do.