![[ t ]](/images/structural/icon_twitter.gif){kind=icon}
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.
What Links Here
An Argument for Building Your Own CMS
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…
What This Links To
What Makes a Content Management System?
I got to thinking the other day: exactly when do you have a "content management system?" We've all built apps that manage content, but when do you graduate from a "relational database with an admin section" (RDBWAAS) to the lofty and deserved title of "content management system?" (Incidentally, I struggled…
Comments
I never looked at it, but doesn't eZ Systems offer such an API based framework called eZ Components?
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?
isn't this how 37signals got big?
maybe instead of finding one, you can build one...
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.
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.
interesting idea. Obviously ATOM could be a lightweight starting point.
Google doesn't know much - most of the links are to heavy iron portal systems from Oracle/IBM, etc.
I did find this, which looks interesting: http://onpubco.com/index.php?articleID=15§ionID=5
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.
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
Like others, I'm not getting it. What's the difference between the CMS API you want and a web development framework?
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.
A year later, has anything like an API based CMS emerged?
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 dev.day.com and Apache.
Deane and everyone, We are developing just the thing you are looking for. Please visit http://www.bitsybox.com to get more info. So far we have the read API, and the write API is soon on the way. Plus, our architecture is professional and solid. Best, Salvo
Add Comment
- Island Inkjet by Kathy Porcher, 18 hours, 35 minutes ago
- In 1998, Bill Gates was an A-Hole by Mark, 18 hours, 52 minutes ago
- Island Inkjet by Kathy Porcher, 18 hours, 54 minutes ago
- Island Inkjet by Anonymous, 18 hours, 55 minutes ago
- Live-Shot dot com by John Jacson, 1 day, 7 hours ago
- Show 5 more »
- CNN's "Hologram" by Deane in 2008
- CNN's Video Irritates Me by Deane in 2008
- USA Today Gets Serious About Blogs by Deane in 2005
- Grokster Goes Bye Bye by Deane in 2005
- Ten Ways Gadget Companies Can Make Us Happy by Deane in 2005
- Show 8 more »