Drupal's RESTful future

TL;DR: services and feeds rock! We need to change the way we look at the server - web-servers are really build-servers.

Intro

Lately at AllPlayers.com I have been spending a lot of time working on API’s for our site and spending some time making Drupal talk web. Luckily, this is something that is being thought about a lot in the community (see: WSCCI, services.module); but, there are some interesting growing pains:

The connection to Drupal: There are a variety of ways to connect to external sites and obviously “the way the web should work”, but I get the explicit feeling that many of types of connections are “toys”. As a site administrator we built out a DLAMP (Drupal, Linux, Apache, MySQL, PHP) install because we are serious about building a web-app! In our engineering efforts, we are probably only slightly interested in handing over our data to 3rd party services, so likely our next interest is in taking on the data for ourselves (which is no small matter).

Get the data

So, we’ve committed ourselves to “big data”; great - how do we do it?! Honestly - look towards to the industry leaders; short of a major engineering effort (which perhaps you should be looking at hadoop, hbase, and map-reduce), we are here for Drupal - and that’s gonna make this fast and powerful: feeds! Target an endpoint, upload a file, or configure the plugin an do what you want, then parse that data with a processor (e.g. XPath, QueryPath, CSV mapping, or build your own). It’s a little like magic! (if you don’t believe me, maybe a demo could convince you. Now let’s get a little more technical…)

Oh the pain…

You’ve got the data but, was that all there was to it? Mostly… but, because we are good researchers we note something about feeds requests: they’re pretty good, but there turns out to be a variety of different ways to do essentially the same thing:

Some observations: the Drupal way seems to be drupal_http_request but, there is also a distinct lack of PEAR dependencies like HTTP_Request; a nice place to ruminate.

Expose your data

Data acquired! But we want to share (easy): fields and views. However, as a respecting netizen you want to share semantically! Drupal already comes feature packed for the web, but we also want to share through API’s. Luckily contrib space has this “solved” with services, where we can expose our data through a variety of servers and varieties of formats.

Thus we can do something like this: GET http://drupal6-services/services/plist/node/1.json and expect

{
  "changed": "1286592762",
  "language": "",
  "uid": "0",
  "type": "story",
  "status": "0",
  "nid": "1",
  "created": "1286592762"
  ...
}

amazingly powerful! (it is also worth noting that the services endpoint can pull from views as well!)

Oh the pain…

The story so far has gotten us everything we need very quickly, but as consumers of many public APIs we quickly note that what we are leaking is Drupal through exposing endpoints. This is actually fairly useful to developers of Drupal, but is probably pretty useless to someone consuming your product, therefore we need to take configure (or theme) the exposed services.

Additionally, given a glimpse of web services future of Drupal this seems particularly pertinent! WSCCI (Web Services Context Core Initiative) is the holding place for the high performance REST server.

Data and the front-end interaction

I probably don’t share very much, but I have a love affair with javascript; and given the amazing HTML5 features and great javascript libraries (jQuery is just the tip of the iceberg - or the first taste depending on how you look at it) - there is a bright future in the browser! So bright in fact: I am of the opinion that “web-pages” should be delivered as apps! There are a lot of great tools to facilitate the concept of a client side app, often examples of this are seen in the Chrome web store (some neat technologies include the cache-manifest).

This leaves me wondering: where exactly does the theme layer live? Particularly, as in a traditional sense, the theme layer seems to live “in the browser”, which means that any processing done server side to render CSS, JS, and/or HTML would be in the delivery of an application - the version of which the client is requesting to be delivered by the server.

About Me