Hacker News Reader

Comment by JoelSutherland | Hacker News Reader

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API:

http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu...

That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint and trade-offs.

Blog Engine CMSs are restrictive because they are Blog Engines! You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

View on HN

The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy.

Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/

Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE ?

Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.

Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard:

http://bergie.iki.fi/blog/introducing_the_midgard_create_use...

I really like the constraints you set on your project: "Build a CMS, no forms allowed". Aloha and other wysiwyg editors can hide the CMS almost totally. Using RDFa to store content is not a bad idea.

If you're interested in integrating VIE into that system, then the EU-funded IKS Project might be able to help you with that: http://www.iks-project.eu/get-involved

For the content management API, have you looked at Content Repositories? There are pretty good specs for standard content management APIs for Java (JCR), PHP (PHPCR) and Node.js (NoCR).

The REST API alternative, CMIS, is unfortunately a bunch of committee-designed mess.

Hey Joel, I remember seeing this post on HN ages ago and tried to find the link recently :) I wanted to show this "api first" approach to someone who was building an XML API for Flash sites. I showed him the Decal API [1] but wanted to give him this as an example a well, thanks for reminding me!

[1] http://www.decalcms.com/page/Decal_API_Quick_Start_Guide

> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.

I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either:

1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time?

2. He was just indicating that headline in position X be 20px, communicating with the layout.

3. He was hard-setting it to 20px.

It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.

The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'.

BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3]

[1] http://www.youtube.com/watch?v=qjgQHzYcxIQ

[2] https://github.com/railsdog/deface#readme

[3] http://spreecommerce.com/

Reply on news.ycombinator.com