Tom Evslin points out that APIs will make or break most of the new web applications. And he's dead right. In fact, API's are where all the really interesting stuff happens, because you get people doing things with your service that you never dreamed of.
Now we're talking specifically about web service APIs here. Because it's the network effects that make the magic. Metcalfe's Law, Reed's Law, even Godwin's Law. Take your pick. So these days, any sensible web services entrepreneur is going to want to get an API on the boil sooner rather than later.
Now I've been doing some work with the “big” APIs, like Google, Amazon and friends. I'm building a set of examples for my new product (due out shortly). One thing I will say is, go REST young man! SOAP interfaces are the suck. They raise the bar to entry far too much. Heck, do you realise that most people not only do not understand XML Namespaces, but are actually afraid of them? Too many nooks and crannies. Too much to go wrong. Amazon, for example, seems to change their namespace on a regular basis – it's date based. What a pain.
The other thing about APIs is that they are very very hard to design and maintain. I've run into this issue quite a bit with my Java Components. It is basically impossible to fix a broken API after the fact, but version 1.0 of anything useful still has far too much complexity to get it all right the first time. Actually, I took an approach to this problem based on some ideas by David Bau, which has worked out quite well. All the callback interfaces in my components use an intermediate abstract class to provide a DMZ for future changes. I've already used this succesfully to fix some problems, without any users having to recompile.
So how can you apply this to web services, where there is no inheritance model? The most important thing is to ignore what you don't understand. HTML is the classic example of this. The second thing is that you must support until death-do-us-part all your declared objects, methods, values and properties. You just gotta. Think real hard about them before you publish them. It's very difficult to get right, but that's programming for you – not as easy as it looks. And finally, don't reinvent the square wheel. You absolutely, positively should look at what other people are doing, how it's worked for them, and what you can do better. Build a Toyota, not a Trabant.
I predict (OOH, dangerous sir!) that a market will develop in helper applications and third party API providers for websites and services. In fact, you can appize (you heard it here first: [æp'aiz]) any site, if you really want to – just look at all the blogification (OK, I'll stop now) going on. So, start your motors gentlemen! We've just got ourselves a new business model.
