By Deane Barker | October 2, 2007 | 23 Comments
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.
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
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.
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.
CouchDb is almost all interface.
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
You should look into Osmek, its a developers dream http://osmek.com. 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.
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.
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
O.M. Osmek now features full CRUD support! The future of the CMS is here.
Does it include uploading of files?
Currently file and image uploading is not supported through the api. But it is on our road map of future features.
Of all the solutions mentioned in the comments, Osmek seems to be the only one to fit the bill. I wish it were an Open Source project available for download.
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 http://www.apicms.com its a downloadable php script with cakephp as framework and theres also a free version available
GeoConsensus is a CMS and CRM without an interface — also integrates mapping as content. Interfaces are developed via API