Skip to content Skip to navigation

Drupal 8 - A Festivus for the REST of Us

The development team was recently given the opportunity to stand up a Drupal 8 REST server with the intent of improving on our D7 content server, learning what's new with the framework and seeing how our content types would fit into the revised architecture. Having just attended BADcamp at UC Berkeley, we were excited to use Drupal 8 and its new special sauce (yml, composer, console, bigpipe, twig, etc).

The foray started with a quick win. Standing up a REST service with Drupal 8 was wicked fast (note: I blame the use of the word 'wicked' on marrying someone from Boston). We leveraged the core web services modules HAL, HTTP Basic Authentication, RESTful Web Services, and Serialization.

Next, we installed REST UI and Self Documenting REST API. REST UI gives you point and click configuration of your REST API end-points and Self Documenting REST API provides...well, you guessed it, a self documenting API for your REST server. REST UI has a very easy to use GUI and made getting endpoints set up a breeze. Self Documenting REST API was easy to set up and while documenting GET fairly well, it lacked some of the detailed documentation for using POST, DELETE and PATCH. I tested the endpoints using google Postman, but other tools such as PAW or DHC would work as well.

First reactions to using Drupal 8 for a REST server were positive. HAL (Hypertext Application Language) is awesome! Hyperlinks between resources in your API make it really great for exploring and understanding how the API works. Tacking '?_format=hal_json' onto a node/{nid} path and getting usable objects was effortless. 

Serving up real content types with Drupal 8 REST services was a mixed bag of success and failure based on the availability of working contrib modules that our field types used. The fierce pace of contrib module development will likely have things running more smoothly by the time of Drupal 8's release slated for November 19, 2015.