Content Management as an API

By Deane Barker • • 6 min read •
Author Description

A good CMS is built from the API out, not the interface in.

AI Summary

This post explores the concept of content management as an API, emphasizing its advantages for developers. The author argues that leveraging APIs enhances flexibility and scalability in managing content, leading to better integration with various applications and improving overall user experiences.

Note

It’s remarkable that this was such a novelty in 2007. Today, this is a requirement, but in 2007, it was hard to find.

Here’s what I want: a CMS that was truly developed from the API out. If an interface comes with it, great. I might use it, I might not.

I’ve talked about this before. Last year, I said this:

When building a new piece of software, you really need to completely divorce the interface from the API. You need to get in the mindset that your app is really just a data store and a set of logic modules that do something. That is your application.

I still believe this. Give me a well-implemented API, and let me write my own interface.

I was working on a client’s site this week. They needed to manage exactly one piece of it – the ubiquitous list of press releases. I debated tossing Movable Type at it, but they were running on Windows and I didn’t feel like supporting Perl in that environment.

So, I custom-wrote it. Yes, call me an idiot, but I actually created a database table, wrote a “News” class, extended that from a “ContentObject” class, built a little database abstraction class, etc. I finally hooked it up to a solid interface and TinyMCE.

The result is fantastic. Client enters a password, and they’re right there in the list of press releases. They can click “Add New Release” and they get a lightweight, focused interface tailored specifically for what they want to do. It’s as tight as it can be.

Why is this surprising and earth-shattering to me? Because I’ve spent years now working with boxed systems. And a boxed system has to work for all types of content, not just my specific content. Their interfaces are necessarily general and not specifically geared to what I want to do.

In working on this system, I was forced to acknowledge this: you will never get a more solid interface than one you custom-code for the situation. eZ publish has a nice interface which you can customize quite a bit, but there’s a still a lot of surrounding…stuff, that makes it a less than optimal system. Most other systems are much worse.

So let’s all start custom-coding our content management systems again, okay? Um, no. The problem is that you have to solve all the same problems all over again – user management, versioning, workflow, preview, etc. In the end, it’s the “glue” code that kills you.

(See this post for the uber-list, or this post over at “Enter Content Here” for the Big 6 that sink a lot of systems.)

And this is why I want an API-only CMS. I want a set of objects that I can use to build my own interface. I want a set of objects that handle all the crappy code that goes with a CMS. I want to build my own generalized interfaces, but also one-off, mini interfaces (“Channeled Interfaces,” I named them once) for people to do certain, specific things.

The problem is that most systems are built from the interface in. This is great – wonderful interfaces are important – but then the API becomes secondary.

In fact, I work with a boxed system now on version 7.0 that is trying to back an API into their interface six years after it was first built. They went from the interface in, and the result is a lot of re-work and changes to get the API to match up to what they’ve had scattered throughout their interface for years.

So, I want a true, native, API-level content management system. Where does such a thing exist? Start naming names.

Links to this – Half-Assed Content Management August 15, 2008
Some content management situations don't require a full-blown CMS. Rather, they required "content-oriented" management of data, which integrates into a larger system.
Links to this – An Argument for Building Your Own CMS September 7, 2009
Content Management Systems just don’t work. : This is an excellent post about something we’ve discussed before – is a “boxed” CMS really worth it? For instance, in this excerpt, the author is struggling with the decisions that the vendor or platform makes for you: See, the problem with a full scale...
Links from this – Your Interface is NOT Your Application May 23, 2006
The interface you interact with when using your CMS is only part of the picture. You need to be concerned with the API that lies under that interface as well.
Links from this – Why Boxed CMSs Can Suck November 22, 2006
I’ve Never Met a Boxed CMS I Like : SitePoint has a brutally accurate post about CMSs and making them run actual Web sites. The first issue is that the very nature of a CMS is not easily boxable, without creating an application that tries to do everything for everyone and fails at doing most things...
Links from this – What Makes a Content Management System? June 30, 2007
Comprehensive post discussing the most common features found in content management systems today.
Links from this – Channeled Interfaces: Hiding the Big Picture June 24, 2006
Not every CMS editor needs access to all CMS functionality, and often this access can be confusing. In many cases, to pays to "channel" the interface down to just the functionality a particular role needs to see.