[cross-posted from the Headshift blog]
That’s a question I was asked a few days ago by a client. It’s a fair question, too – there’s no point in building features into systems unless they provide some benefit, so why would you want to spend time and effort doing this? And for that matter, what exactly IS an API?
The acronym stands for “application programming interface”, which is a typically over-engineered way of saying “means of putting information in and getting information out of your system without having to type it yourself”. Typically you’ll provide the API with some information, and in return the system will process and spit back some other data. There’s any number of analogies that you can use, but one of my favourites is the cash machine. That’s pretty much an API for your bank – you put in your card and enter your PIN, ask the bank for money, and it then dispenses cash. The information you’re providing is the data on your card and your PIN, while the bank is supplying you with cash and a little paper slip telling you how big your overdraft is.
An “API” for a bank is a good thing if you want to get at your money, but why is it such a big deal for a piece of software?
To start with, very few software systems these days exist in isolation. If it’s an accounting package, you’ll probably want it to hook up to your bank so you can send and receive payments automatically. If it’s an ERP system, you’ll find it useful if you could send your purchase orders electronically to your suppliers rather than relying on the steam telephone. And if you want to tell your customers where your outlets are, you can embed a Google map into your website to plot their locations so that your customers can find you.
All of these are examples of systems using APIs, but it doesn’t stop there. Increasingly, systems are providing APIs without necessarily having a clear idea of what they’re going to get used for. In some ways, that’s a violation of my sweeping statement about there being no point building features without having returns – but the point here is that there’s no guarantee that you’re best placed to know *what* those returns might be.
Take Moo, for example. They print things – stickers, business cards, postcards and so on. They’ve also got an API. So what the hell would a printing company do with an API?
The answer is, suprisingly, quite a lot. Former Headshift colleague Tom Armitage created an application that takes a set of Flickr photographs, calculates their average colours and creates stickers. They’re very tangible, suprisingly beautiful and almost completely pointless – unless, that is, you’re Moo who make money for every sticker that they print. Another example is Barcode Sticker-o-Matic that lets you create QR code stickers. Previously, creating QR codes was a pain, and creating QR code stickers was even more of a pain – but mashing up the two things creates something very much easier and useful.
Another example (and bear with me while I unashamedly pimp some of my own creations) is Twitter. Their API enables you to create tweets with code, rather than the website. So I’ve used this to create Twitter bots that tweet the high and low tides of the River Thames; and tweet the values of various stock markets every hour. The first example is something of a play thing (although as an aside, I actually think you can gain some value to be gained by providing an inanimate object with a “personality”), but the second could conceivably be useful if you needed a peripheral update of how badly the markets were doing.
So much for the entertainment value, but what about the potential business value for providing an API?
There are two things to consider. The first is that you could potentially make it easier for your customers to deal with you. If your clients can place orders directly onto your system through your API, that’s going to speed things up. It’s also going to cut down on errors and duplication, particularly if you can give them information about lead times and stock levels there and then. And on the assumption that the easier it is to deal with you, the more people will, that should translate through to the bottom line.
The second thing – and to me, the most powerful – is that your customers may want to interact with you in ways that you’d never thought of. It’s fairly unlikely that Moo realised that they’d end up printing QR codes when they wrote their API, and I’m absolutely sure that Twitter weren’t expecting me to come along and impersonate the River Thames. And the same probably goes for for huge numbers of other organisations as well. Imagine if Sainsbury provided an API for their home shopping service. How long do you think it would be before someone created an iPhone application that allowed you to scan the barcode on the last tin of beans in your cupboard, and automatically add that into your basket, which would then be automatically ordered as soon as the value triggered their free delivery option. Oh, and interrogated your Google calendar to find the slot when you weren’t planning to be out for evening? I don’t work for Sainsburys – and they’ve certainly never tried to ask me about what I want from them – but if they provided an API for me to play with, then I’d definitely be having a go at it.
I’m going to make a wild prediction that no corporate software system will ship WITHOUT an API in three years time, and that organisations that can’t provide an interface for their customers are going to find that an increasingly difficult omission to justify. So the question is not so much, “what’s an API and why do I want one”, as “what’s my API going to do and when can I have it”…
