Decoupled CMS - "Headless" Drupal Options

This past week at Drupal Costa Rica, I had a nice conversation with Todd Ross Neinkerk of Four Kitchens, who was there presenting on the notion of de-coupling content management and content display (here's video of a similar talk he did in Austin). I also spoke with Jesus Olivias who recently did a great Spanish-language podcast with Omar Aguierre on the topic, and he was kind enough to give me his two cents.

Decoupled Drupal is officially now "a thing". It's all happening. If you're curious why this is exciting people, see my previous blog post on the topic: what's the big deal with headless websites? In this blog post I will dig into the technologies at your disposal for exploring Decoupled (aka "Headless") Drupal today.

Decoupled Drupal Today!

For those looking to develop Decoupled Drupal websites right now, you can totally do it with version 7. Even though there's excitement about the upcoming Drupal 8 release — and I'll detail the action below — you don't need to wait to get started with these techniques. Drupal 7 still has a long life ahead of it, and with the right contrib modules it is usable for anyone looking to build decoupled websites today.

The most well-known interface for Drupal 7 and an alternate front-end is the Services module, which has a very Drupal-ish manner (e.g. hook_services_alter()) of exposing various interfaces. It comes with built-in REST and XML-RPC interfaces, and allows you to expose, nodes, users, taxonomies and other core data fairly easily behind custom endpoints (API paths). You can also use it as a basis for specifying your own custom services.

There's also the restWS module, which exposes any Drupal entity on its existing URL based on headers. This module is the basis for Drupal 8's REST module, which we'll discuss more later.

Finally there's a really interesting package from the developers at Gizra, the Restful module, which is also entity-centric, but takes a different philosophical approach. Rather than exposing Drupal's internals, it allows developers to define what data they specifically want sent in response to a request. It also allows the exposure of some entity types and not others (e.g. the "Article" nodes, but not "Pages"). This module is definitely more developer-centric, but they have some nice blog posts about how they use it with AngularJS that will help you get up to speed.

The Future of Decoupled Drupal in Version 8

The possibilities open up significantly with Drupal 8. Core includes both a REST interface module and a brand new routing system built on the Symphony2 HTTP kernel. This provides a lot of opportunity for decoupled implementations both for beginning and more advanced developers.

The REST module is a souped-up version of what you got from RestWS in Drupal 7. Your core entities are all eligible for exposure, using the JSON+HAL format by default. This gives consumers of entity data the ability to follow "links" to other data sources — for instance you can pull the definition of a content type from any node.

Making Drupal's native entity data model accessible to other apps via REST takes only a few clicks. Views — also in core for Drupal 8 — natively supports "REST export" as a type of display. You can configure your way to a robust REST API into your content without installing a single extra module.

For those looking for more specific or nuanced functionality, the core HTTP routing framework is one of the most exciting pieces. It's a general upgrade for how all Drupal modules handle requests, replacing the legendary hook_menu() with a fully-featured HTTP server. You can set up custom routes, define controllers for callbacks, and manage responses based on headers, status codes, and all the other things one cares about once you make the mental leap from "serving pages" to "talking HTTP" in your application.

For developers with experience building server-side applications in Python, Ruby on Rails, or Node, this is a welcome change. It opens the door to much more sophisticated implementations with Drupal — powering the backend for complex mobile applications, serving as a lightweight integration point for different kinds of data, even acting as a pure API to external application developers.

Much More To Come

There's still more to come. A big part of the equation is what's on the other side: now that we know how to build a REST backend in Drupal, what's the client? There are many exciting answers, which I'll address in another post, ideally with code samples for AngularJS, Backbone, and others.

There's also exciting movement in the decoupled direction in WordPress, where the WP-API project aims to have a native REST/JSON server bundled into the 4.1 or 4.2 releases later this/next year. I'll be doing a dive into the potential for those implementations soon as well.

Are you building decoupled applications? Do you have tips tricks or techniques to share? Let me know and let's spread the word!