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.
- 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.
- 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.
- You only ever have to write a service once. If you write a service, any server (renderer) can return your data to the requester.
- You have complete atomic control over which services your Drupal installation would provide. You never expose more than you want
- 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.