Within the technology/software world, "headless" refers to the concept of software that doesn't come with a front end. It's difficult to wrap your mind around software with no user interface, or a web site with no web pages, so we're going to switch from the abstract to a concrete example.
Non-Headless CMS (Content Management System): WordPress
First, let's take a common, non-headless CMS: WordPress. There are a variety of pieces here:
- database to hold content/pages
- admin backend to write content and manage plugins and themes
- rendering engine to turn push content through themes and render a viewable page
- the WordPress application framework itself, running on PHP
This CMS is "full-stack", it does the entire job of hosting, editing, and displaying the content. Also, as a traditional full-stack, all-in-one application, there are a few other characteristics relevant to the headless discussion:
- The editor used it tightly coupled with the WordPress concept of content. How pages are shown, their layout, how the media is stored, is all part of the WP design, and that design is also tightly connected to the idea of a "web page".
- As installed, it is self contained and not designed to be interacted with systems from outside the site. It might query other systems, say, showing the current weather via a plug-in when you load a page, but there isn't a way for inbound traffic to, for example, retrieve just the text of a page (without getting all the menu, layout, and graphics, i.e., the whole page).
Headless CMS
Now let's contrast this to a hypothetical headless CMS. What does it consist of? Much less:
- database to hold content (but not "pages")
- a content editor
- an interface that lets outside systems ask for content (via an API)
That's it. Missing is anything that would actually show a web page. In fact, the content isn't even being written with the idea of a "web page". Think of a listing for an item for sale, say, a flashlight, you might have a description (with no layout specified), some images (with no rendering size specified), some customer reviews (but as raw text, not behind another tab on the page) and many product specifications (but not in a HTML table, just a list of entries with feature name and then the rating/measurement for that feature).
Importantly, we can see that the content, as held in the database, is not a "web page", or even necessarily written to be on a web page or easy to show on a web page. And there's no software here that will display it as web page.
If your first thought is "So a headless CMS is a CMS where you can't even see anything! What's the point?!" you're technically correct, but we're only halfway through.
The Strength of Headless: Multi-Channel
The full concept of headless is completed with the idea that in today's world, you likely want to display your content in many different places. Returning to that flashlight, you might want to show that content via:
- your own web site
- your Amazon store
- your weekly sales flyer
- your Android app
- your iPhone app
- your Google AdWords listing
- your Facebook ad listing
Each of these is a very different structure and we can see that "a web page" doesn't work for all channels. To solve this multi-channel content approach, we turn to a headless CMS, which is designed without a bias toward a single type of method of displaying or using content. We can build smaller, custom connectors that allow each channel to display the content in a way that is native to that channel.
To show the content on "the web channel", you'll have to build your own "custom head". One custom head would be a "web site display", and the user would go to that URL, the custom head would then ask for the headless content, and the custom head would then be free to display that in any way it wanted for that web effort. If you wanted to roll out a new web site, you wouldn't have to worry about migrating the content, only re-engineering the custom head that displays it. Both custom heads could be running at the same time, since the content they were requesting is stored in a format that is independent of formatting and display.
For other channels, such as your Amazon store, you wouldn't build a "custom head" so much as a "data connector". Amazon is the head here after all. It just needs to get to your descriptions and images. And since a headless CMS is designed from the start to be queried from the outside, and without HTML as its base format, it is easier for all these "data connectors" to get that data in a useful way.
To expand on your headless universe, you could build micro-apps designed to interact with just a small portion of the data. For example, you could have one app that just let people see summaries of your blog posts.
Headless: Opinion
First, although we've used a CMS as the example here, there are many types of software that could be developed in a headless fashion. Nearly anything with a pure client/server architecture could be done this way. Philosophically, headless was built as a solution to multi-channel content distribution issues, and thus it follows that it will be more attractive to you if you need to interface with many channels, especially at scale. A good fit might be 3M, with over 60,000 different products, obviously distributed in nearly every single channel on the planet. They clearly have a very large and complicated content distribution scenario, and headless is a concept they should definitely consider.
On the opposite side, Betsy's Etsy Knit Kaps Store, has no need for headless technology. She's an entrepreneur running her business solely through one channel. There are only a few products, and there isn't the IT budget to develop custom data connectors, nor would it be worth the effort when cutting and pasting the descriptions into her Ebay listings would take just half an hour.
Scale is where headless technology will shine, and the more you turn up that dial, into multiple countries, languages, displays, technologies, platforms, the more headless becomes a contender for consideration.