Content Management as an API

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.