Headless CMS

Without content man­age­ment systems, content creation work would be a lot more com­pli­cat­ed. 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 ap­pli­ca­tions in play at the same time. To be able to handle this, one either needs multiple CMS, which means that content must be manually trans­ferred 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 tight­en­ing of a classic CMS. The system takes in integral com­po­nents to make it com­pat­i­ble with a wide variety of outputs. This is possible because the frontend and backend of a headless CMS aren’t mono­lith­i­cal­ly linked with each other anymore.

To make the use of these systems as simple as possible, a mono­lith­ic link between the frontend and backend is used. For example, on the ad­min­is­tra­tive 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 re­quire­ments of the system when creating content. This applies both to the number of outputs as well as the use of the pro­gram­ming language (for example, WordPress uses PHP). To avoid these con­stric­tions, you can switch to a headless CMS.

A REST-API (Rep­re­sen­ta­tion­al State Transfer-Ap­pli­ca­tion Pro­gram­ming 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 com­mu­ni­ca­tion. With such commands, a client can access in­for­ma­tion on the server to retrieve or change it. In principle, REST follows the ar­chi­tec­tur­al 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 ap­pli­ca­tions via a server. Access therefore doesn’t only work locally.

• Addresses identify things: Different types of ap­pli­ca­tions need different file formats. With REST, the URI/URL doesn’t refer to a resource in a par­tic­u­lar format, but instead to the element itself. Clients request the element in the desired format for content ne­go­ti­a­tion.

• Messages are self-ex­plana­to­ry: 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 hy­per­links for simple nav­i­ga­tion.

By adhering to these ar­chi­tec­tur­al prin­ci­ples, the com­mu­ni­ca­tion between server/API and various clients can work flaw­less­ly. This makes REST ar­chi­tec­ture perfect for a headless CMS API.

The described sep­a­ra­tion is useful from two per­spec­tives: From the point of view of backend de­vel­op­ment, 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, re­gard­less of what tech­nol­o­gy it’s pro­grammed with.

The frontend de­vel­op­ment view also offers benefits: As a web designer, you’re no longer bound to the re­quire­ments of a content man­age­ment system with a headless CMS. The pro­gram­ming language is no longer defined. Because of this, the con­struc­tion of mobile apps on various platforms is now possible. Only the raw data needs to be received and processed. This offers the pre­sen­ta­tion lots more wiggle room than is possible with most classic CMS.

Another benefit is the dynamic request ca­pa­bil­i­ty. 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 in­te­grat­ed into the site structure at any time without it needing to be reloaded.

By sep­a­rat­ing the headless CMS backend from the in­di­vid­ual 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 man­age­ment system, then it can be in­de­pen­dent­ly 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 pro­gram­ming languages
• Flexible frontend design
• Con­ti­nu­ity via de­cou­pling
• Dynamic data

There are already some providers of headless content man­age­ment 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.

• Con­tent­ful: 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 func­tion­al backend – from the ground up instead of re­build­ing a pre­ex­ist­ing, 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 al­ter­na­tive, there are different sub­scrip­tion variants to choose from.

• Con­tentstack: Built.io, the man­u­fac­tur­er of multiple digital solutions, offers a paid headless CMS with Con­tentstack. 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 man­age­ment, 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 license. There are also paid variants with pro­fes­sion­al support and al­ter­na­tive licensing offers.

To decide which headless CMS offer is right for you, you need to research the in­di­vid­ual re­quire­ments 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 rec­om­mend­ed. If you don’t have the necessary know-how for the in­stal­la­tion and setup of the system, then you should take advantage of a paid variant to benefit from the ad­van­tages of this content man­age­ment style.

Since headless CMS is discussed in­creas­ing­ly more often, the providers of tra­di­tion­al content man­age­ment systems are re­align­ing them­selves. For example, since version 4.7, WordPress has added a REST-API as an in­te­grat­ed 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 ap­pre­ci­ate the scope of the content solution, including the template engine, can continue to work without losing any func­tion­al­i­ty. But those who want to use the CMS for the man­age­ment of app content, for example, profit from the included interface. Drupal can also be trans­formed in a hybrid, as from version 8 onward the open source CMS offers the pos­si­bil­i­ty to publish content in further frontends using RESTful web services.

Whether you should trade in your tra­di­tion­al 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 ad­van­tages beyond the possible quantity of output media, but this rarely justifies the extra effort. The use of a decoupled CMS also offers no ad­di­tion­al 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 par­tic­u­lar­ly effective if you want to realize large projects. Mul­ti­chan­nel ca­pa­bil­i­ties, 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 pro­fes­sion­al frontend de­vel­op­ers – they can be used with total freedom, as made possible by REST-API.

The re­de­vel­op­ment of the content man­age­ment system (not really a further de­vel­op­ment, since only half of the system is still used) is a reaction to the changing re­quire­ments of the internet. The special features of smart­phones, the Internet of Things, or virtual reality, make a reeval­u­a­tion of the way that content is created and published necessary. Headless and decoupled CMS are only the beginning. Therefore, even if working with a tra­di­tion­al CMS is still suf­fi­cient, you should continue keeping track of new de­vel­op­ments. In view of the swift de­vel­op­ments 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.