This article will tell you everything worth knowing about headless CMSs (sometimes called decoupled CMSs). You'll learn what headless exactly means, how they differ from the CMSs you know, and what their uses cases are.
A headless CMS has its front-end component (the head) removed, and what remains is a backend delivering content via an RESTful API. Because of its backend-only nature, it does not care about how the content is displayed: its focus is just on storing and delivering the content, and nothing more.
Its counterpart is a standard multi-purpose CMS – often referred to as monolithic or coupled – like WordPress or Drupal. Let's take WordPress as an example, which consists of several components: 1) a database where the content is stored; 2) a web app in which editors work with the content (also known as the admin interface); 3) a part of the web app for managing the website's design; 4) a front-end which takes the content from the database and generates HTML pages. Imagine that we remove (3) and (4) from this setup. The head of the CMS, the website itself, is no longer there: what remains is a backend for handling content storage and distribution, and a web app for editors. That's it, that's the entire CMS.
Unlike with a monolithic CMS setup, a headless CMS is not the only thing you need to create a website. By design, it lacks the features to do so, as there is simply no concept of theme or template. A developer would need to build the website, and use API of the headless CMS to access the content.
At first, this may seem counterproductive, and there could be objections to this different paradigm: "working with a single software is simpler than working with two", or "building a front-end is hard and time-consuming". These are fair points, and they do apply to a variety of cases. This is why there is no definitive answer to the question "is a monolithic CMS better than a headless CMS?" It just depends on your needs, there are use cases where one is better than the other, and vice versa.
The most prominent use cases for headless content management are:
It's not only for websites, though. A headless CMS usually delivers content through an API, which means that it can deliver content anywhere, on any device. This is great news for mobile app developers, because with this approach the same backend can deliver content to an iOS app, an Android app, or any other medium.
So, headless proves to be hugely beneficial for cross-platform publishing and custom user experiences. It makes publishers, designers, and developers happy, who in turn will provide great products for their users. But if your use case is just a simple company website with only a handful of pages, a headless CMS may be an overkill. Your good old WordPress will perfectly cover that use case, and dozens of similar ones.
Traditionally monolithic CMSs have been trying to fix their mistakes and promote themselves as headless. The most popular PHP options for going down that path are:
Overall, we can see that these two options try to make the CMS work in way that they were not designed to. In fact, both WordPress and Drupal don't scale well when using them as headless, because their monolithic nature doesn't allow them to be as flexible and performant as needed.
Unlike Headless Wordpress or Headless Drupal, Contentful was built from the ground up to be a headless CMS. This means that you won't find many of the unsatisfying things that you would see in a monolithic CMS that was repurposed to be headless, such as insufficient performance, limited capabilities, bad documentation, and inconsistent support.
Of course, this requires you to adopt a different mindset and introduce concepts such as content modeling and search-based management (instead of tree-based). However, we are sure that the advantages that this new paradigm can provide are real and substantial, which is why the change is worth the effort.
While we can say that there is no single right approach and CMS for every use case, we strongly believe that the separation of concerns typical of a headless CMS will help make building most of real-world projects easier, and this is why we built Contentful.