Integrating a new content management system (CMS) into your existing ecosystem of tools and services may be challenging, but not with a headless CMS with a quality API. Read on to learn how headless CMS API can help you prepare for the future.
There is no doubt that in order to connect content-as-a-service with its headless API-first approach to other best-of-breed microservices you have to have a good quality API on both ends, so that the services communicate and integrate well.
But what does a good quality API really mean? Of course, there are many different angles you can consider (e.g. it has to be testable, well documented, with solid error reporting, secure…). In this article I am focusing on the quality of a headless CMS API, and more specifically the required API capabilities you’ll need to be able to face typical challenges, while integrating a headless CMS into your existing ecosystem of apps or when building a new app or a website.
Why should you consider these capabilities? Imagine you select a headless CMS without critical API capabilities. Although you might not necessarily need these right now, what about in the future? How would you tackle this challenge? What if there is no workaround and you need to switch the platform? Save time, money, and more by thinking ahead!
Now, let’s have a look at the critical capabilities of headless CMS API:
This is the most crucial part of an API of every headless CMS, as it allows you to retrieve stored content and deliver it into multiple channels (website, mobile app, IoT, and others).
There are several aspects of this API you should consider based on your needs:
Although, headless CMS provides great tools for content editors to create and manage content, you as a developer will certainly get into situations where you will need to do it from your code:
In the world of headless CMS and microservices it is very important to be able communicate with other applications and services. When it comes to headless CMS you will typically need to notify your other application or service when content changes to allow the application respond accordingly.
For example, if you are using a search-as-a-service (e.g. Algolia) to provide a full text search experience for your online articles, you will need to update the search index of your articles every time a new article gets published. The reason is that search index is stored and search capabilities are provided by that search service, i.e. outside of a headless CMS.
This notification mechanism of a headless CMS is usually ensured by webhooks. As stated above, think of webhooks as programmatic notifications that let your application know when something changes inside your headless CMS project — structured information about the type of change and the affected content are usually attached.
Similarly to other types of API, flexibility of webhooks is also important. For example,the ability to be notified not only when content gets published, but also when content gets moved to another step within the content management workflow (e.g. to notify a translation service about content to be ready for translation before publishing it).
Here’s some examples of how webhooks can be used:
There is no doubt that many content editors will need to use existing external content within the content they are producing in a headless CMS.
For example, you may need to use images from a Digital Asset Management (DAM) system for your articles. You can copy and paste the image URL, which is not very user friendly and hard to maintain. Or, a better option would be to let content editors search and pick the image from a DAM system within a headless CMS UI directly, and store just a reference to the image (some unique identifier) that does not change over time.
Another example would be leveraging external taxonomy by integrating with an AI tagging service providing automated tagging by extracting keywords and other information from assets uploaded into a headless CMS.
For these purposes, a headless CMS usually provides a certain type of UI extensions framework allowing you to integrate with external systems and use their content with the content in a headless CMS. At the same time it usually helps developers to a customize content authoring experience within a headless CMS to fit content editors needs (e.g. you can create a Youtube video selector or specialized Markdown editor).
Now you should have a better idea of the key capabilities of a headless CMS API to be able to build complex integrations, including:
I am sure you have some more aspects that you may find important to consider for quality headless CMS API -please don’t hesitate to share them in the comments below. Looking forward to your inputs!
Petr Vozak is the Technology Partnership Product Owner at Kentico. He works with technology partners to enrich Kentico Cloud and bring greater value to those using it.