Bonus Prediction: REST ye merry!

Prediction: APIs rule, and REST will come to rule APIs in 2007

Google rules the Web 2.0 world. They are the alpha and the omega, from Google Maps (which popularized Ajax and got the whole thing started back in 2005) to being the primary acquirer and exit strategy for many Web 2.0 companies. Google is also the whole alphabet in between, and their publishing of APIs for their applications re-ignited the "mash-up" concept from Web 1.0, and changed the face of web apps we see today.

Google is wise and omnipresent, but they aren't omniscient. Back in 2002, when the current round of API design decisions were made, Google had the choice of creating an API in well-known media-darling SOAP, or the little known academic paper-protocol REST. They chose SOAP. Not that SOAP was such a bad choice, but with the benefit of hindsight Google is now heading in another direction, and Yahoo has already reached the promised land.

SOAP (originally Simple Object Access Protocol) was a neat idea -- to replace the bulk and complexity of integration schemes such as CORBA with a simple combination of XML and HTTP. Great idea, but to provide fully-functional enterprise integration SOAP had to expand, eventually absorbing much of the complexity of the protocols it meant to replace.

Enter REST. Representational State Transfer is the brainchild and 2000 PhD dissertation of Roy Fielding. Fielding observed that one of the great advantages of the HTTP specification (of which he was also a contributor) was that the client-server, stateless, cacheable, and layered design made access and architecture for the specification straightforward. REST extends these concepts to application-application communication. Very broadly, REST maps the basic CRUD operations (create, retrieve, update and delete) to familiar HTTP operations (POST, GET, PUT, and DELETE). As an additional conceptual benefit, these operations also map analogously to the database operations INSERT, SELECT, UPDATE, and DELETE.

Boiled down, the idea is to have applications interact through conceptually simple HTTP access for exchange of resources -- remote resources, as opposed to remote procedure calls. API creation is then a breeze, because the access methods are already broadly familiar, and the receiving applications need only be ready to respond to requests based on the request information in the HTTP header - say for HTML (web pages), JavaScript (Ajax requests) or XML (application requests). Ruby on Rails has good REST support now (through the SimplyRestful plugin) and will have REST as a part of the core going forward.

In the Ruby/Rails world, URL's are beautiful and informational, and one of the downsides of REST are URLs that are more machine- than human-readable. Still, as applications are increasingly designed with integration and mashup in mind, you can expect REST to rise in prominence in 2007.