This blog post is part of the SaaS Headless Content Delivery Architectures Series (SHCDAS).
The term headless differentiates CMS vendors that include toolsets for content delivery, sometimes called traditional CMS vendors, from those that do not, which are considered headless. Traditional CMS vendors provide toolsets to generate static files, replicate database changes, and so forth, as well as frameworks for building content delivery applications. Headless CMS vendors provide hosted environments for content management with service endpoints for wrapped in SDKs for content delivery. Traditional CMS vendors may provide endpoints that wrap application services as used in headless CMS, but internally use native APIs to access data resources directly rather than using HTTPS services exclusively.
The headless CMS metaphor refers to the separation of technology and responsibility between content management and content delivery by using HTTPS endpoints rather than APIs.
- Head: Content delivery tier, accessed by visitors on the Internet.
- Body: Content management tier, accessed by CM users.
- Headless: CMS vendors provides bodies; CMS customers provide heads.
Bodies provide HTTPS service endpoints wrapped with CDNs and native SDKs and a media library wrapped with a CDN. Headless CMS vendors provide integrations with third parties such as the major static site generation tools.
SaaS headless CMS solutions MACH architecture:
- Microservice: Applications are built using HTTPS services of various granularities.
- API: Architected around APIs over HTTPS, typically using JSON to represent data
- Cloud: Built for the cloud and specifically Software as a Service (SaaS).
- Headless: Content delivery solutions depend only on HTTPS API endpoints that wrap those endpoints, not vendor-specific code for content delivery logic.
With SaaS (Software as a Service), a headless CMS vendor administers hosted content management environment for each CMS customer, though some vendors allow customers to deploy the CMS in private clouds. Content management environments expose an extensible user interface and HTTPS service endpoints for content management, content delivery, and media delivery including server-side image manipulation, all typically wrapped in Content Delivery Networks (CDNs). Events in the content management system can trigger webhooks that signal and pass data to other systems.
Vendors of systems that are not headless typically provide content delivery software that customers must use to retrieve content from the CMS. Content delivery software typically depends on a single technology platform, such as Java, .NET, PHP, or otherwise. Content delivery systems do not simply wrap HTTPS service endpoints, but access databases or other resources directly. Static content delivery software retrieves content from the CMS during build and deployment, such as to generate files. Dynamic content delivery solutions retrieve content when visitors request resources from the solution.
Headless content delivery does not depend on vendor-specific toolsets or application server APIs, but on SDKs that wrap underlying HTTPS JSON endpoints provided by the CMS vendor. Applications, which can run in the visitor’s browser or device, on application services in the content delivery tier, or both, stitch together resources and services from multiple vendors as well as any hosted by the customer.
With SaaS headless CMS, the CMS vendor is responsible for administration of hosted environments for its customers, although some CMS vendors support private cloud implementations.
Headless solutions separate Content Management and Content Delivery into numerous smaller services used to construct the CMS UI and to make data available for content delivery. Headless solutions separate the use of service from the logic and data used to implement that service. Content delivery solutions use HTTPS endpoints in the CMS for read operations, while the CMS UI uses additional services to write. With SaaS headless CMS, the CMS vendor is responsible for administration of hosted environments for its customers, although some CMS vendors support private cloud implementations. Headless vendors do not provide software to generate files or platforms on which to build dynamic content delivery solutions, but Software Development kits that abstract access to their service endpoints. Whether during a solution build process or afterwards, accessing published data from a headless CMS involves the same HTTPS services.
If you know of additional advantages and disadvantages of headless CMS relative to CMS with content delivery toolsets, please comment on this blog post.
Advantages of SaaS Headless Content Delivery
- Headless content management fits modern MACH architectures, allowing CMS customers to take full advantage of the advantages of SaaS.
- SaaS headless CMS vendors manage hosted content management solutions for their customers, including all infrastructure and software upgrades for content management and content delivery services.
- Because SaaS headless CMS vendors provide scalable infrastructure for data storage and access for content delivery including media, all over HTTPS, headless CMS customers have no responsibility for vendor-specific data storage infrastructure in the content delivery environment, only for their use of that data as needed.
- Headless content management can reduce hosting costs by scaling services individually as needed.
- Headless content management can reduce CMS vendor lock-in, or vendor-specific architecture, coding, tooling, hosting, integration, and otherwise.
Disadvantages of SaaS Headless Content Delivery
- Headless does not provide features for inline editing in the CMS. CMS users edit content through a browser-based user interface rather than in the context of the website.
- Headless content delivery does include experience management features such as tracking, profiling, testing and optimization, personalization, and otherwise. Headless solutions depend on applications that integrate services from vendors selected by the CMS customer.
- Not all headless CMS provide the concept of an entry hierarchy to represent parent/child relationships between entries, where such structures can be useful for building navigation including site maps and other features. Solutions can infer entry hierarchies based on the URLs associated with each entry.