Services API Module - Future of Services for Drupal

Earlier this week Dries Buytaert wrote about CMIS a proposed standard to enable interoperability among content management systems. And in that article he said he wants to "push harder" for Atom as a default output format for Drupal so that Drupal be CMIS compatible in the future.

At Drupalcon Szeged Peter Wolanin (Dries colleague from Acquia) presented a talk "Page serving and rendering (XHTML/XML/JSON, etc.) - now and Drupal 7" in which he talked about the different ways Drupal may go about rendering output in formats other than (X)HTML.

Of course these two items are part of the same thing: namely getting Drupal to serve up content that isn't a "web page". So before I get to what I want to say, I encourage you all to go off and read "How I Explained REST to My Wife" if you're unclear about why you'd want Drupal spitting out something other than a web page. Or, if you don't feel like reading that, just know its all about the ability to build robust platform independent applications that can make use of the digital assets you already have sitting there in your Drupal powered website. This is all very exciting stuff and I'm thrilled that Drupal is looking to include web services in core. There is no question they belong there.

Currently Drupal is very much geared towards generating HTML and to a lesser extent XML in the form of RSS feeds. 'Page rendering' in Drupal is basically dozens of calls to functions that are focused on generating their piece of the page and having those pieces rendered as HTML by calls to 'theme' functions. Of course depending on which page is being requested, logic will dictate which pieces get asked for and therefore which pieces get rendered. And all the while, Drupal also takes care of setting the HTTP headers and rendering the 'head' of the page.

Some people have been proposing that maybe instead of functions handing off rendering to a 'theme' function that will only return HTML, you might pass structured data to other kinds of functions and have them return something else like JSON or Atom or what have you. On the surface this sounds great. This would solve how to get the different pieces of a page rendered together in a different format.

However, if you're asking for a different format, chances are you don't want everything that is typically found in a page. So, you would either have to figure out how to suppress parts of a page during the rendering process, or render the entire page and throw away the parts you don't need before sending the requested format back to the requester. Besides that it would take all sorts of gymnastics to decide which kind of rendering was taking place throughout the page rendering process. On top of that, you would need different renderers for each possible format maintained right in Drupal core. And, if that weren't enough, you'd have to provide a means for people to 'alter' each possible rendering.

Long story short, the focus seems to be on manipulating the current page rendering process (which is well suited to rendering a human readable HTML page) to render something entirely different (which it is ill equipped to do). Basically people are trying to pound a square peg through a round hole.

What I find most curious about the work being done is that the problem has literally already been solved (if not quite yet perfected) in the form of the Services Module. And, for quite some time there has been a Drupal Services group dedicated to "an abstracted API for implementing web services within Drupal 7".

I hope you choose to read "How I Explained REST to My Wife". I also hope you take a look at the services module. If you have you'll why services module is a more suitable alternative to the problems presented by trying to get Drupal's page rendering process to work differently and why services module lives up to its name.

  1. Services only give you what you request (nothing more or less). If you request a node from a service all you get back is the node.
  2. You only have to have as many renderers (servers in services module speak) installed as you want. If you're never going to return JSON you never need to install a JSON server.
  3. You only ever have to write a service once. If you write a service, any server (renderer) can return your data to the requester.
  4. You have complete atomic control over which services your Drupal installation would provide. You never expose more than you want
  5. You have complete atomic access control over who can access which services on your site

One final point. Services aren't just about rendering data. They are also about accepting data. While I haven't read the CMISspec, I would assume that it won't be enough for Drupal to have the ability to make requests and serve responses to a CMIS enabled server, but will have to be able to accept posts as well. And that is something Drupal currently only has limited ability to do now, but could theoretically be much more flexible with Services module in core.

andre

September 23rd 2008 11PM
By: andre

 

Comments

IT Crowd

I think this clip from The IT Crowd http://wiwapia.com/en/IT_Crowd sums things up nicely

REST-style storage

hi andre,
thanks for this great post that reminded me of the interesting conversation about Services i had with you on the last evening at Drupalcon in Szeged ...

I think what this ultimately boils down to is making Drupal a REST-style data storage / data provider. CMIS has REST-style bindings (see Alfresco's CMIS), buzzy DBs like CouchDb do and there is some exciting work on JS-clients (Dojo's RESTful JSON).

And that means, as you write, this is not by any means just an issue in the theme/presentation layer (the GET in REST) - it raises a lot of questions in the data model (PUT,POST,DELETE anyone?). Ruby on Rails is also often mentioned in this context. I not familiar w/ rails. But, i think, Rails has a concept called "ActiveResources" (here's a REST + ActiveResources tutorial PDF), that exposes models as REST-resources for CRUD operations ... considering that ActiveResources have been around in Rails for over 2 years, one should be able to find out how that architectural element has worked out for them ...

If services got into core, it should be quite easy to expose Rails-style Active aesources (nodes) with a generic server contrib-module that hooks into nodeapi et.al. which would make Drupal resources much more REST-y.

frega

At one point that issue was

At one point that issue was called something like "Get Services Module into Core" :)

Machine-readable data for every URL

"Ideally, every URL would have a human readable and a machine readable representation." (From "How I explained REST to my wife.")

That's why the approaches in Refactor page and node rendering and Enable loading and rendering into JSON, XML, etc. are so important. Better data/display separation should help Services API be much more powerful and easier to implement for more things (CCK fields, taxonomy terms, etc) but I don't see how Services replaces the need to fix the underlying architecture in ways that mean "one URL, multiple (potential) ways of displaying the data".

benjamin, Agaric Design Collective

2 points

The author of the article neatly sidesteps the point you raise in the very next lines:

"Wife: So people would have to make machine formats for all their pages?
Ryan: If it were valuable. "

Yes I know, "Who is to say what is valuable?", but we also have to be realistic. Not everything gets every machine readable format.

Still, the second point: Drupal url's are nothing more than a string of arguments tacked onto index.php. At the end of the day we can juggle arguments or manipulate their order to conform better to a standardized URL structure.

What about something like example.com/service/method/node/1 - which could just as easily be example.com/node/1?service/method. Whatever the scheme, as soon as a service is requested we call for the services way of rendering (provided a method exists).