Why use RESTful? Web Services and Drupal explained

RESTful is the native API of web browsers. When you put some website’s address into a browser, that’s an implied REST expression called a “GET” of the resource at that address. In response to that GET request, the web server on the other end returns a web page. However, REST is much more than requesting the resource (data) at some address. Just like using any website, one is able to Create things, Retrieve them afterwards, perform Updates to them, and eventually Delete them. That Create -> Retrieve -> Update -> Delete cycle is called “doing CRUD” (really), and that in a nutshell is what creating and using a RESTful system is all about.

In the “early days” of the Internet, when someone wanted to make a printer or some other machine programmatically communicate over the Internet, more complex systems with names like SOAP, XMLRPC and AMF were used to handle that communication. Then around the year 2000, a smart guy named Roy Fielding pointed out that the web itself was an API and these complex systems were not only a bother to create and work through, but needless because what they were offering was already built into the web itself.

Now, Drupal is a content management framework whose essential purpose is to create a website of some sort. You are probably familiar with some websites including information from other websites, such as a Twitter feed or Facebook friend status. This including of other website’s information can be accomplished “the old, hard way” via scraping the page that normally shows this data, via SOAP/XMLRPC or that communicating of information can be accomplished “the new, shiny RESTful way” which takes less effort and by it’s nature is universally supported.

This is essentially machine-to-machine communications, and is how an iPhone/iPad/Android/game console/printer or virtually any other device communicates on the Internet. This is using REST.

The topic of our Developing RESTful Web Services and APIs class is how to use the new Services 3.0 module. Services 3.0 provides an API for Drupal module developers to create a REST API of their own design. Using Services it’s most basic level, one can install and enable a set of built in APIs that will allow remote programmatic administration of that website (thru secured authentication of course!) What I detail is the more ambitious creation of a series of programmatic resources, demonstrating how to create a useful API of the type that could support anything capable of programmatic control.

For example, you could have a site where you provide users “alerts” when items the users have shown interest become available. Additionally, those alerts can be seen on Facebook and in an iPhone app. Your Drupal site providing these alerts can use a custom module and Services to publish an example.com/alerts/uid API that the Facebook and iPhone apps use to manipulate that information. Using REST for this communication is more lightweight on your web server because the Facebook and iPhone app logic is able to request that information specifically, rather than an entire web page where they would scrape off the data they want, or get that information through the more complex SOAP or XMLRPC methods.

This is also how one could have a mobile and/or console game’s universal high scores and user community forums present in-game as well as simultaneously on the web. One could have a Drupal site using Services to publish an API for “doing CRUD” with high scores and interacting on the community forum. For the Drupal site, business as usual, but for the mobile and/or console game they are getting that data via a RESTful communication with the Drupal site. For the mobile and console game developers, this type of communication is easy. And through Services, it’s also easy for the Drupal developer.

Further, I use Services to create “custom on-demand digital products” at a Drupal/Ubercart store, with that on-demand creation taking place on a remote cloud server. I walk through how that is setup, and my architecture for scaling the environment should my custom digital products go viral.

And the best part, REST is how one creates Web Services. What are Web Services? They are the future of everything. Really. Remember up there where I mention machine to machine communication? Web Services are the creation and publishing of APIs to “do CRUD” with things that people care enough to pay real money for access. Such as access to commercially controlled data like music, movies, or even stock and bond research and trading. Web Services is taking REST and wrapping it in commercial activities. Some event venue could publish a ticketing API, and then charge ticket brokers for access. The list of possibilities are endless. And that list is expected to be how all commercial services in the future will be conducted. (Make your eyes really big when you read that last part :)

In summary, our Developing RESTful Web Services and APIs class covers how to create an API with Services 3.0, as well as how to support your API customers (who may not be using Drupal) (and who may be dumb as rocks) how to successfully use your site’s API.

At the class, I give out and walk through an API Shell, which took over a month to create. Next, students begin creating their own API with architectural guidance by myself and other Larks trainers. To facilitate this, an example API’s is step-by-step created, with time for the students to implement their component in their API as we go along. For individuals or groups with a specific project they are planning or have in development, a 3rd day of additional guidance and support is also available.