The API

I’ve just been sitting here the last 3 days tightening up the ccHost Query API 2.0, getting it ready for wide public release. As of this writing about 85% of ccMixter is driven by the API and I figure if we’re going to integrate into social sites to spread the good word I need to make it “real” – that is, robust, by actually checking parameters and returning meaningful error messages and other boring and friendly geeky things.

What a coincidence, here comes the API.

There’s no point in comparing the two, the ccH QAPI is a really basic affair with simply a view on looking at the data. To be honest, it’s mainly about making my life easier by having a uniform programming model to add features into ccMixter.

The API is really about Big Game.

A quick jargon lesson: When a programmer writes the code that makes up a software application it is not done in a vacuum. They are instructing some piece(s) of hardware to act a certain way. The problem is, there are thousands of different pieces of hardware and their instruction sets are all randomly different. So along comes a guy or company or a group of gun-toting Libertarians open-source movement, somebody to relieve that pain who says “I’ll make it so you don’t have to worry about the hardware. I’ll do this by writing a piece of software that goes between your application and the hardware. You just (re)write your application to a new instruction set that I give you and I’ll take care of the rest.” So you forget about the hardware’s instruction set and invest time, energy and money in learning this other guy’s instructions that he calls an “operating system.” Things are going OK except that all your friends are driving faster cars and even faster women and seem flush with the green. You figure out they’re having the bling life because all their applications are on this whole other operating system. Now along comes another set of bozos that say “Forget about all those operating systems. We’ll make it so you don’t you don’t have to worry about that stuff. You just (re)write your application to a new instruction we give you and we’ll take make sure it runs on all those operating systems.” So now you embark on re-investing your time, energy and money in learning this whole other thing and now you’re good to go with what these guys call an “application stack” – yes, as in stack of trays like in a cafeteria. You only worry about your “food” (aka script) on the top tray and the forget about the rest of the trays.

No matter whether the instruction set you use is meant to obscure hardware differences or operating differences or networking protocol differences the concept is called a “platform.”

Targeting a specific platform can be tricky because when you commit to one of these you become dependent on it until it is more cost efficient to rewrite the thing yet again. So at some point you are make the critical decision to pick which platform you are going to take to the dance. If enough application developers pick the same platform then the folks that provided that platform are the Big Winners.

The Web changed the game a bunch but there’ll always be a group of folks who want to be the Grand Gate Keepers and Key Masters. They stock their cubicles with developers who love to invent APIs and platforms because it’s just plain fun. When facebook invented their own platform and the site exploded because of all the cool platform widgets that developers wrote (typical facebook widget guy can pull down $2k per widget which is about a two day job) and birds were singing again. Except at Google which is so big they share mini-APIs out of strategic good will more than anything else. They don’t need to share their actual platform so much, just the applications.

I’ve forgotten where I’m going with this other than to say I hope it’s somebody else who goes and builds the widget and it isn’t left to me.