Resources

What's the difference between an API-only vs. API-first approach?

image of female developer at work for api-first architecture article

There are countless marketing blogs and articles across the internet that talk about what a content management system (CMS) with an API-only approach brings you and your organization in terms of flexibility. But when marketing teams start addressing more technical aspects like an API's role in a CMS architecture, the conversation can become confusing since there are sometimes different conclusions being drawn.

Despite their usage or context, these terms generally refer to other CMS buzzwords, like headless and decoupled, and we're going to take a look at how you can parse out what they mean.

Start building in a free trial environment, see a demo, or talk to an expert—select one of these paths and start however you would like to!

The evolution of the CMS and the no-API approach

A little over a decade ago, CMSs did not include APIs in their implementations. The back end of the CMSs from that time—where content was created, managed and stored (as well as where design and customization happened)—was tightly linked to the front end of the CMS, where content was displayed to the end user. The two were housed together. These kinds of no-API CMSs still exist today, but you will see them now referred to as coupled CMSs.

Content teams enjoy no-API CMSs because they are extremely user-friendly. A no-API CMS comes with built-in themes and templates that allow content creators to easily customize the front end; that being the case, organizations who have a no-API CMS don’t have a huge reliance on IT in order to create and manage content, operate the CMS or display content to end users; therefore, as a technical leader, you don’t have to spend much time dedicating your development teams to assist in content delivery.

No-API CMSs are great for smaller-scale projects, like blogs, but for what you get in simplicity and user-friendliness in a no-API CMS, you sacrifice flexibility. Not only that, but ever since the Internet of Things grew legs in the early 2010s, and ever since the public GraphQL specification was developed, the no-API CMS architecture lagged behind due to its rigidity.

The end users that organizations were trying to reach were readily adopting devices all across the spectrum as they grew smarter and Internet-capable. No longer were audiences only reading content while sitting in front of their computers—they were now glancing at watches in the mornings for news updates or asking Amazon Alexa to give highlights. All of this was happening before they ever sat in front of their computer for the day. Organizations that fail to reach their audiences in these ways will leave their audiences unengaged.

To combat this trend, some CMSs began separating out the back end and front end so they were not housed together. They introduced an API to the situation, which connected the two by taking the data from the back end and displaying it on any number of front ends for their end users. New breeds of CMSs were engineered—ones that were built from the ground up with an API that offered companies more flexibility to address the challenges of the technological landscape of their day.

API-only architecture

One of these new breeds of CMS was what is referred to as the headless CMS. Unlike no-API CMSs, the headless CMS is an “API-only” approach.

In an API-only CMS, organizations don’t get the front-end code they would need to build a complete experience, whether that’s a website, an app or anything beyond those two channels. They simply get the API, and possibly a back end interface to input data.

One of the advantages of this approach is that your organization is enabled to select the front end that works best for your use case, giving you a lot more flexibility than before. Not only that, but as new smart devices emerge, you’re already covered with your API-only CMS since it is designed to connect to any front end through its API. When weighing an API-only CMS against its no-API counterpart, there are other benefits, too, like:

  • API-only CMSs are more secure since there is no direct access from the front end to the database.
  • Deploying changes is generally faster.
  • Often comes with out-of-the-box integrations to help the CMS fit into your tech stack.
  • Can drive down costs since you are not required to change the back end each time you add a new channel.

Of course, there are caveats.

If the no-API CMS enables content creators to easily manage and display content to their audiences without heavy IT involvement—an architecture that sacrifices flexibility for user-friendliness—the API-only CMS does the opposite: you will have more flexibility, but you will also need back end developers to handle the back end, and front-end developers to handle the content delivery to ensure content reaches your audiences in a seamless way. This is because API-only CMSs separate your code base and your responsibilities, requiring that you have specialized engineers for both the back end and front end.

This means that your content creators, who plan and produce content from idea to publish, suddenly have less involvement in delivering that content to your audiences, which could be problematic since they are often the visionaries who take time to determine what will be appealing. API-only CMSs also often lack an out-of-the-box preview system that allows content creators to see how their content is displayed. You need a front end for that.

The no-API and API-only approaches then become two opposite sides of a spectrum where you, as an organization, must choose what you are willing to sacrifice in order to meet your basic content needs—and that’s where the friction exists for decision makers looking at different solutions.

API-first architecture

But there is in fact a happy middle ground between these two approaches in what is called the API-first approach, often called a decoupled CMS.

An API-first approach acts like an API-only CMS—the API is always available to take data from the back end and present it to applications or other channels that the end users will see; however, the API-first approach takes this a step further by giving you the tools, templates and other rendering options that your organization will need to build out a site. This is because, despite functioning independently from one another, the back end and the front end are still linked together since the front end is predetermined with a specific delivery environment.

Companies that leverage their CMS to achieve an API-first approach carry all of the same flexibility they would have with an API-only approach:

  • In an API-first approach, there is still a separation between the front end and the database, increasing security.
  • Deploying changes is faster.
  • Comes with out-of-the-box integrations to help the CMS fit into your tech stack.
  • Drives down costs since you are always not required to change the back end each time you add a new channel.

Suddenly it isn’t a matter of whether you will sacrifice usability or flexibility in order to best engage your audiences as they consume content; with an API-first approach, you get the best of both. Content teams can create and manage content while being able to preview it, ensuring the finished product is engaging and reaches your audiences wherever they are.

Considerations

If you want your content creators to still have the tools and templates they enjoy from a no-API CMS, but with the flexibility of what you get with a API-only CMS, then an API-first approach is what you should consider in order to achieve engaging experiences across all of your current and future channels.

To learn more about how Brightspot can empower you to achieve an API-first approach, book your product demo today!

Share
About the Author
Mark is a Manager, Digital Content at Brightspot. When he's not gleaning insights from various developers from the company, he spends his time cooking new dishes at home with his wife and two hyperactive cats.

Related resources

A term coined in 2007, a webhook allows different apps to send user-defined callbacks to one another via HTTP POST requests. In plainer English, webhooks allow notifications to be sent from one app to another app when a certain event occurs.
Organizations leverage a variety of programming languages to build content management systems. Among the most popular are C#, Java, PHP and Python. And though some technical experts will swear by their favorites, it begs the question—which is the best to use?
While headless CMS is not a new concept in the digital space, today it’s an increasingly attractive proposition for businesses looking to move their digital transformation efforts forward in an impactful way.
What is data science, and how can it improve an organization? More specifically, how can the insights of a data scientist drive results for a business that's publishing hundreds, if not thousands, of pieces of content each year? We take a closer look.