What Does It Mean for a CMS to Be Headless?

This blog post provides perspectives on what it means for a content management system to be considered headless. A content management system structures and separates data from its use, allowing domain experts to maintain content used by delivery systems such as websites and mobile applications. Rather than providing HTML generation engines, headless CMS expose content as JSON over HTTPS services. If you have perspectives on what it means for a CMS to be headless, please comment on this blog post.

Decoupled

Headless content management is said to be decoupled from content delivery, meaning that the customer has greater control of the tools and phase(s) in the solution lifecycle at which to apply different levels and forms of coupling.

• Coupling in [Headless] CMS – Deliverystack.net

The Headless CMS Metaphor

In the headless CMS metaphor, the body is the content management system, where CMS users maintain content. The head is the content delivery system used to make that content available to the visiting public. Headless CMS provides bodies, but not heads.

• The Headless [CMS] Metaphor – Deliverystack.net

Traditionally, content management systems included platform-native content delivery software that customers would install as a CMS and to generate static files or to access data from the CMS. Headless CMS solutions do not include any software for generating files and expose only HTTPS APIs with platform-native software development kits (SDKs) that simplify their use. Reducing direct coupling in the solution architecture has numerous advantages, most of which derive from using SaaS.

• SaaS Headless CMS Vendor and Customer Responsibilities – Deliverystack.net

SaaS

Using Software-as-a-Service (SaaS) applications reduces Total Cost of Ownership (TCO) and improves ROI for CMS most implementations. SaaS headless CMS customers can use the CMS vendor’s content delivery network (CDN) to scale global caches of content and media used by other applications without the need to understand and manage applications or application servers.

SaaS CMS vendors host content management environments and content delivery services for their customers, as well as SDKs for implementing content delivery solutions. SaaS headless CMS vendors are responsible for content management environments and content delivery services including media.

Content delivery solutions implemented by customers access content delivery APIs in the build process, while generating HTML, or using end-client logic. Headless CMS customers are responsible for implementing, hosting, and deploying content delivery solutions that consume data from the CMS, often using CDNs to host static files, optionally including server-side logic and often using JavaScript to implement applications on the client. Headless CMS customers are responsible for content delivery solutions including implementation, hosting, and deployment.

• Three Major Phases for Data Access in Headless Content Management Solutions – Deliverystack.net

Not all headless CMS software is SaaS. Customers that choose not to use SaaS can provision and manage instances of some headless CMS software on their own infrastructure. This may be especially relevant for open source CMS projects where customers want to factor their custom enhancements into the CMS solution. Alternatively, some vendors can provision and possibly co-manage instances of their CMS software in the customer’s cloud.

No Generation

A headless CMS does not include any facility to generate HTML or any other output format. A headless CMS provides a user interface for managing content, HTTPS APIs for accessing that content, and webhooks that signal other applications about events in the CMS.

While CMS is multichannel, the heads in most headless CMS solutions typically generate HTML or any other output format. To facilitate developers building websites, mobile applications, and other solutions, headless CMS vendors provide numerous SDKs, frameworks, component libraries, examples, and other elements for different technologies in use by content delivery solutions.

SDKs

Rather than content delivery engines, headless content delivery vendors provide SDKs that wrap content delivery services. To access content delivery services, headless CMS vendors provide software development kits (SDKs) for the various technologies used by their customers.

An SDK differs from an installation of the software in that it allows use of a product without installing that product separately. When custom code invokes APIs in headless CMS SDKs, the SDK invokes HTTPS services that communicate with the CMS.

Technology Independent

Headless CMS is omnichannel, meaning it intends to service content delivery points other than websites. Headless CMS is used to power mobile devices, kiosks, in-store displays, menus, video game content, print, and almost any other medium imaginable.

Headless CMS vendors support as many technologies as customers require without absorbing the cost of implementing and maintaining low-use SDKs. Platform technologies generally start with JavaScript and JavaScript libraries but can also include at least .NET, apple, android, Java, PHP, and Ruby. Customers can always call CMS APIs directly, avoiding any dependency on a vendor SDK.

Microservice Architected

Any CMS can expose services, but a headless CMS is typically service-oriented, API-first, and built upon its own services. The CMS user interface is an application separate from the CMS and uses the same APIs exposed to external developers using the product. Microservice-architected applications expose every possible function as an API and every system event as a webhook. Working with microservice-architected applications has its own consistency, as all applications conform to parallel patterns.

Just as a headless CMS can include components used for content delivery, not every service-oriented application must be microservice-architected. Simple, custom applications developed by small teams may not benefit from microservice architectures, especially where the application exposes no external API or a simple external API.

Vendor Independent

One goal of headless CMS is vendor independence. Especially in a market where vendors can come and go, CMS customers must be able to migrate between vendors relatively easily, and headless is a step in that direction. As mentioned in the blog post linked in the section about coupling, headless CMS maintains some coupling between content management and content delivery systems, and hence some of the relevant risks.