Using WordPress as a headless CMS must sound like blasphemy for many developers and users, that reduce WordPress to just a blogging software. But with the advent of the REST API in 2015 we wanted to try using WordPress as the backend for our own mobile app: Beergarden Finder Munich.
What is a REST API?
REST is short for Representational State Transfer and does not describe the API itself, but the underlying structure and architecture of the API. The purpose of REST is to provide an easy to consume, machine readable endpoint to share data, information and content.
The idea is to provide this data without a predominant state for all sorts of clients. From Single-Page-Webapps, to mobile apps, digital signage or trading applications, the usage of REST in todays world is everywhere.
One of the most important principles of REST is called HATEOAS, Hypermedia as the Engine of Application State. HATEOAS describes the need to navigate the API through URLs, instead of states or variables. The result is a very easy to understand structure, that shapes the data.
An example is the WordPress API. You can find all of our posts in a JSON format within the REST api on the endpoint http://wpmunich-2019.lh-cloud.de/wp-json/wp/v2/posts, if you add a post ID on the end, you get all the available information for a single post, e.g. http://wpmunich-2019.lh-cloud.de/wp-json/wp/v2/posts/364.
What is a headless CMS?
A content management system is headless, when there is no frontend itself attached to the system. The content is then exposed via a RESTful API and then consumed by external clients. These clients a usually separate from the CMS.
The main advantage is the ability to create a ‘pure’ content hub and to be able to repurpose the content in a variety of different ways. For example for websites, mobile apps, virtual reality, wearables and anywhere with access to the internet.
In the case of ‘Beergarden Finder Munich’, WordPress acts as a headless CMS to provide a mobile app with the data needed to show the information about the beergardens.
Adding Data to the api
The work on the REST API began as a Google Summer of Code project somewhere in 2013, main contributor back then was Ryan McCue. With the release of major versions in 2014 and 2015 the plugin became stable enough to be used in production projects.
The idea of creating the Beergarden Finder Munich was originally conceived together with Jens Wiese from allfacebook.de and resurrected in 2015 at the UX Munich conference.
After a short concept phase we were pretty sure about the needed data for the app, so we started implementing our needed features as a WordPress plugin. The base of the data-collection was a custom post type, which was enriched by a number of metaboxes to collect the data needed for the frontend.
Custom endpoints for the app were registered with the ‘json_endpoints’ hook. In total we exposed 5 new endpoints to display the map, beergarden details, a menu, comments and to handle the newsletter signup.
Writing the app
Developing the app itself was very straightforward. We developed the app as a ‘titanium’ project to be platform agnostic and because we were more comfortable in a javascript syntax than in Objective-C or in Java.
All we did is populate a mapview with the data provided by the REST API and add some detail and content views. The only challenge was the voting and commenting mechanisms, as we had to post content back to the WordPress system through the API.
Conclusion
Using WordPress as a headless CMS is definitely an option. We are hopeful, that we will one day get some useful hooks, filters and actions to deactivate the frontend to ease the burden on the system, but until them we just deliver an empty theme.
If you want to be a perfect poster-child, you could use the theme part of your WordPress system to deliver the documentation for your ‘headless’ CMS and the API.
One thing that worries us is how a post-Gutenberg WordPress will handle content exposed in the API, as the baseline content will be a lot more opinionated as it is today. In our eyes it will become (a bit) harder to use WordPress as a content hub for a wide variety of playout-clients.