Headless CMS

Without content management systems, content creation work would be a lot more complicated. Instead being entered directly into the code of a website, the CMS contents are entered via a backend and output by the system in the frontend. The works quite well as long as you’re only managing a single website. Meanwhile, editors and content managers often have multiples sites and applications in play at the same time. To be able to handle this, one either needs multiple CMS, which means that content must be manually transferred from one to the other, or can instead use a headless CMS, which enables output in any number of media.

A headless CMS is both an extension and a tightening of a classic CMS. The system takes in integral components to make it compatible with a wide variety of outputs. This is possible because the frontend and backend of a headless CMS aren’t monolithically linked with each other anymore.

To make the use of these systems as simple as possible, a monolithic link between the frontend and backend is used. For example, on the administrative interface of WordPress, you can alter the look of a website without any web design knowledge using the template engine. This also means that you’re bound to the requirements of the system when creating content. This applies both to the number of outputs as well as the use of the programming language (for example, WordPress uses PHP). To avoid these constrictions, you can switch to a headless CMS.

A REST-API (Representational State Transfer-Application Programming Interface) is an interface that is less complex but more flexible to use. A REST-API uses the defined HTTP request methods such as PUT, GET, POST, and DELETE for communication. With such commands, a client can access information on the server to retrieve or change it. In principle, REST follows the architectural style of the web. REST-APIs (often called “RESTful APIs”) are built according to these criteria:

• Servers provide resources: A REST-API is also available to external applications via a server. Access therefore doesn’t only work locally.

• Addresses identify things: Different types of applications need different file formats. With REST, the URI/URL doesn’t refer to a resource in a particular format, but instead to the element itself. Clients request the element in the desired format for content negotiation.

• Messages are self-explanatory: Each message on the server is self-contained and doesn’t refer to any previous ones.

• Resources given with links: Within REST, objects are linked with one another using hyperlinks for simple navigation.

By adhering to these architectural principles, the communication between server/API and various clients can work flawlessly. This makes REST architecture perfect for a headless CMS API.

The described separation is useful from two perspectives: From the point of view of backend development, it helps the desire to spread content through more than one output. In a headless CMS, it doesn’t matter what kind of platform is given for the output of content. The REST-API only provides the data (in the form of JSON). This can be read by any frontend you want, regardless of what technology it’s programmed with.

The frontend development view also offers benefits: As a web designer, you’re no longer bound to the requirements of a content management system with a headless CMS. The programming language is no longer defined. Because of this, the construction of mobile apps on various platforms is now possible. Only the raw data needs to be received and processed. This offers the presentation lots more wiggle room than is possible with most classic CMS.

Another benefit is the dynamic request capability. Renewed content requests on a website on a classic CMS are followed by a reload of the entire page. The REST-API, however, delivers dynamic data that can be integrated into the site structure at any time without it needing to be reloaded.

By separating the headless CMS backend from the individual frontends, a practical situation arises: since trends in web design are subject to regular changes, it’s useful to adjust the frontend of your own website from time to time. If this isn’t bound to a database and content management system, then it can be independently edited. Editors can also create, manage, and publish other content while working on a new frontend.

The benefits of headless CMS:

• Unlimited number of frontends
• Can combine different programming languages
• Flexible frontend design
• Continuity via decoupling
• Dynamic data

There are already some providers of headless content management systems on the market, but there are more every day. The providers listed below differ primarily in offering a paid total package or a free open source variant. There are also various hosting offers available.

• Contentful: The Berlin-based team has been working on the principle of headless CMS since 2011. By doing so, they’ve developed their system – including a functional backend – from the ground up instead of rebuilding a preexisting, classic CMS. But the offer is only available for free to a limited extent.

• Directus: The provider Directus goes in a different direction. The system is primarily offered for free as an open source package. For those who want to rely on a premade hosting alternative, there are different subscription variants to choose from.

• Contentstack: Built.io, the manufacturer of multiple digital solutions, offers a paid headless CMS with Contentstack. Thanks to a REST-API, content creators have access to an easy-to-use backend that can provide content to the web, mobile apps, and the Internet of Things. This offer is primarily suitable for large companies.

• Cloud CMS: This service provider offers its headless CMS as a cloud service. It functions more or less like other offers, but instead of running the content management, database, and interface on its own host, they’re offered on the cloud. Only in the high-price segment of the offer is a self-hosted CMS provided.

• eZ Platform: The company eZ Systems has been offered since 1999 with the open source product eZ Publish as a classic CMS. The old concept was finally scrapped 16 years later in favor of a headless CMS with the eZ Platform. It is also open source: The product is freely available under the GNU GPL licence. There are also paid variants with professional support and alternative licencing offers.

To decide which headless CMS offer is right for you, you need to research the individual requirements and knowledge. For those who have their own server and can create an open source CMS, the free versions of eZ Systems or Directus are highly recommended. If you don’t have the necessary know-how for the installation and setup of the system, then you should take advantage of a paid variant to benefit from the advantages of this content management style.

Since headless CMS is discussed increasingly more often, the providers of traditional content management systems are realigning themselves. For example, since version 4.7, WordPress has added a REST-API as an integrated component. In earlier versions, this could only be connected via a plugin. The extension didn’t make it a headless CMS, though: WordPress becomes a decoupled CMS instead. Users who appreciate the scope of the content solution, including the template engine, can continue to work without losing any functionality. But those who want to use the CMS for the management of app content, for example, profit from the included interface. Drupal can also be transformed in a hybrid, as from version 8 onward the open source CMS offers the possibility to publish content in further frontends using RESTful web services.

Whether you should trade in your traditional system for a headless CMS or not depends primarily on what you plan to do with it. If you only want to present your content on a website, such as a blog, then getting rid of the frontend isn’t a good idea. Headless CMS does offer advantages beyond the possible quantity of output media, but this rarely justifies the extra effort. The use of a decoupled CMS also offers no additional value in this case: Why implement an interface when you only need to use the built-in frontend of the system?

Of course, if you want to present your content on various platforms, it’s a different story. Headless CMS is particularly effective if you want to realise large projects. Multichannel capabilities, websites in PHP, Python, or Ruby, apps for iOS or Android – these present no problem at all. Editors and other content creators can manage their content as usual via the backend interface. Headless CMS (and decoupled CMS, when used correctly) are now professional frontend developers – they can be used with total freedom, as made possible by REST-API.

The redevelopment of the content management system (not really a further development, since only half of the system is still used) is a reaction to the changing requirements of the internet. The special features of smartphones, the Internet of Things, or virtual reality, make a reevaluation of the way that content is created and published necessary. Headless and decoupled CMS are only the beginning. Therefore, even if working with a traditional CMS is still sufficient, you should continue keeping track of new developments. In view of the swift developments of the past few years, it could be that classic CMS will soon be just as poorly adapted to the habits and needs of many users as static websites currently are.