Content Management as an API

By Deane Barker on October 2, 2007

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.

What This Links To
What Links Here


  1. I’m hoping you did this in c#.NET. If so, I want in! I want to help. I built a massive big (buggy) ASP system a few years ago, it spits out static asp pages. I’m sick of it, and want to move it to .NET with me. Dont have the evening to do it all myself.

    Get an open-source project out of this maybe?

  2. Come on Dean, no one thinks about content management systems more than you, why don’t you just start defining your dream API on Gadgetopia. Once you have the API refined with the help of your readers, you can start an open source project. There are a lot of great developers waiting to jump on a well defined project that addresses real needs. If you’ve found you needed it, I’m sure there are many others as well.

  3. Habari is well on it’s way to becoming much of what you need. Chuck the administrative components you don’t need. Help us build out the API as you’ve described.

  4. Hi, I’m the developer of Onpub (linked in the post above) and stumbled on this post from looking at my referral stats. Anyway, I’d be really interested to hear what you think about Onpub. I have a similar philosophy to you when thinking about how a CMS should be designed. That is, not with the API as an afterthought. Well, I’ve been trying for the past few years to develop a CMS which focuses on an API that enables many different website frontends to be built on top of it. I’ve yet to release an example Onpub website frontend. I’ve written a bunch for sites I’ve developed, but haven’t released any code publicly, yet. I realize that eventually I will have to, since most folks don’t want to code a frontend from scratch, but would prefer a working example they can customize. But, OnpubAPI is designed in a way that folks can code a frontend from scratch if they preferred to. Also, the API code can be totally decoupled from the Onpub UI code, if necessary. If it piques your interest and you have any feedback, feel free to post to the forum or drop me a line at corey at onpubco dot com.

  5. Hello Dean

    You should check again QuickelSoft CMS. That is exactly how I build this product.

    The root of the system is just a framework to help you manage your content in an SQL Server database. Everything you want to use is an object (a Content Item, a user, a group, an access control list, a folder, …). I do a lot of unit testing on the framework and then I developped the user interface on top of the objects.

    You can also build whatever user interface you want (web interface, Windows application or through a command line batch file).

    In fact, if you want some help, the code of the QuickelSoft CMS front end is not obfuscated and you can check it with Reflector to see how it works.

    Have a look and do not hesitate to contact me

  6. What’s the difference between the CMS API you want and a web development framework?

    Find me a framework with an O-R mapper with permissions, versioning, workflow, multiple rendition support built-in. A content management-based app is different in many ways than a regular app.

  7. Apache Sling. It has a powerful REST API (which supports CRUD and query, the latter via SQL or XPath) as well as all the Java APIs associated with Jackrabbit. Details at and Apache.

  8. You should look into Osmek, its a developers dream Its a centrally hosted system with no install. Osmek’s API gives you access to your entire account, in just about any format, including JSON, XML, HTML, Serialized PHP, and template responses.

  9. The problem is, as Salvo Lavis mentions, a write API is essential. Doesn’t seem like bitsybox has it yet, and neither Osmek – correct me if I’m wrong.

    Though I do like the initiatives.

  10. O.M., Osmek does have the ability to update section items, contacts, make comments, and subscribe through the API. It is not a full blown write API, but it covers all of the scenarios I have run into. Check out their Osmek.php documentation

  11. hey. maybe i have developed a cms which is a bit like described in the article. its a really small an simple php script. you can write content and add images to it. trough an api you get the content read with html tags and an array with the url to the images (full and thumbnails) thats it. so its perfectly for small sites that dont need any comments or something fancy. just a static design template and a div container where the content is that should be dynamic.

    maybe you are interested in then checkout its a downloadable php script with cakephp as framework and theres also a free version available

Comments are closed. If you have something you really want to say, email and we‘ll get it added for you.