Mapping URL Paths to Content Entries with Headless CMS

This article describes various techniques that solutions can use to map URL paths to content entries in headless content management systems. Content management systems (CMS) separate content from presentation, which allows business users to maintain content for which developers write code to present that data. CMS supports reuse and consistent presentation of textual content and binary media across websites, native mobile applications, and other channels.

Headless content management systems expose content as JSON (JavaScript Object Notation) through Webservice APIs. Frontend applications in any technology on any platform invoke CMS Webservice APIs to retrieve content, which they embed in HTML or other mediums. The primary use of any CMS is to manage content to power websites, which generally consist of pages. A client such as a browser requests a URL from the frontend, which either serves static HTML generated previously, or generates HTML dynamically and transmits that to the browser.

Every URL involves a path, which may be as simple as / for the home page or consist of some number of segments, such as /path/to/page. Each URL path may correspond to a data record (entry) in the CMS, though multiple URL paths may be associated with a single content entry, some segments of the URL path may identify records in other systems such as product information management (PIM), and some URL paths may have no correspondence with entries in the CMS at all.

Every entry in the CMS is associated with a content type, which defines the fields into which CMS enter the data that makes up that record. Each entry also has a unique identifier, but because they are not human-friendly, most solutions avoid exposing these identifiers to users and visitors, who generally find URL paths to be more usable. To retrieve the record associated with a URL path, something must determine the content entry associated with the URL path requested by the client.

One of my previous articles discusses some techniques that headless CMS use to associate URL paths with content entries:

• https://www.linkedin.com/pulse/hierarchies-hierarchical-urls-web-content-management-systems-west-pd8ic/

This article describes the reverse process: how to determine the content entry associated with a given URL path, such as to retrieve data to use when rendering the page at that path.

Most headless content management systems use field values to associate names/slugs or entire URL paths with content entries. In addition to placing the burden of managing URL paths on the user, requiring them to manually specify a URL path for each content entry, this requires developers to map URL paths to content entries, which typically requires knowledge of the content type of the entry associated with that URL path.

You can use one or more of the following techniques separately or in conjunction to map URL paths to content entries in the CMS. As an example of using different techniques for different URLs, you might use static site generation to create files to service some URL paths but use application server logic to retrieve content from the CMS at runtime for other URLs. As an example of using multiple techniques in conjunction, the first segments of the URL path may identify a content entry or static file, while subsequent segments of the URL path could indicate a record one or more additional content entries for the client to retrieve while rendering the page.

Static Site Generation

With static site generation, a process iterates all content entries use to define entries that have URLs (page entries), generates files (pages) using data from a content management system, and deploys those files to a Content Delivery Network (CDN). With this approach, URL paths map directly to files on the file system. Along with advantages such as reliability, scalability, and performance, other than implementing and maintaining the static site generation and deployment processes, this requires minimal effort by the developer.

CMS API Returns Content Type and Entry Identifier

The content management system may provide a Webservice API that, given a URL path, returns the content type and entry identifier associated with that path. This approach requires an extra step to retrieve the metadata before the data, where network latency between the frontend or client and the CMS can have a negative effect on performance.

CMS API Returns Content Entry

Rather than returning the content type and entry identifier associated with a URL path, a CMS Webservice API returns the entry itself, which identifies its content type and unique identifier. Very few headless CMS products provide an API that retrieves the content entry associated with its URL path without knowing its content type and potentially even its unique identifier.

CMS Query

All content types used to represent records that have URLs include a common field, such as to store a slug/name or the entire URL path. Whether using GraphQL or another proprietary CMS Webservice API, the custom solution constructs a query across all content types to retrieve the entry with the URL path from any of those content types.

CMS Search

The solution uses a CMS Webservice API to search for an entry associated with the URL path.

Application Server Logic

Server-side logic at the frontend determines the content type and entry identifier, which it then retrieves from the content management system. Typically, this involves branching logic based on the URL path, where specific paths are associated with specific content types. Such logic can become burdensome to maintain, and may require code updates, testing, and deployment for any new content type.

Client-Side Logic

This approach is similar to using application server logic but runs on the client (browser) rather on a sever.

Custom Service

With this approach, the solution implements a Webservice API that returns the content type and entry identifier associated with a given URL path or returns that entry itself.

It’s All Meta

Users associate metadata with content entries, for example by selecting some number of tag values in a field of each content entry that represents a page on the website. To determine the URL path of an entry or the entry associated with a given URL path, the system applies some logic to these metadata values, and then either constructs the URL path or accesses CMS APIs to retrieve the entry associated with that path.

Search Index Query

The solution maintains a search index that includes a field for URL paths, and passes the URL path to a Webservice API that accesses the search index to determine the content type and entry identifier associated with a URL path. If the search index contains JSON that represents the entry in the CMS, then the search API can return that JSON rather than returning the metadata that identifies the content type and entry identifier.

Digital Experience Composition

I will leave it to the vendors to comment on possible Digital Experience Composition (DXC) approaches.

Conclusion

Determining how to generate URLs for content entries and how to map URL paths to content entries is an important aspect of implementing a content management solution. This article discusses some possible techniques for generating and resolving URL paths to content entries. If you know of additional mechanisms for constructing URL paths or mapping paths to content types and content entries, please comment on this article.

I will maintain this content at:

• https://deliverystack.net/2024/05/21/mapping-url-paths-to-content-entries-with-headless-cms/

Related discussion:

• https://www.linkedin.com/posts/johnwest3_cms-headlesscms-composable-activity-7190939629389283328-Sc0A/