As more and more web-based companies look for new ways to distribute their service and enable third parties to help them build out their services, the availability of APIs seems to grow larger every day.

It’s now possible to develop applications for social networks like Facebook and MySpace, for retailers like Best Buy and just about everything in between.

Offering an API seems to be the internet equivalent of wearing the latest high-street fashion. And it needs to stop.

When I read that non-profit microfinancing startup Kiva is now offering an API, I couldn’t help but roll my eyes.

First, let me make it clear: I love what Kiva is doing. Microfinancing is a great thing and I think organizations like Kiva are making great use of the internet to do really meaningful things.

But Kiva’s API, which enables third party developers to access key data points from the service, seems a little bit like overkill.

The problem, as I see it, is that there are far too many APIs being offered. There may be plenty of developers out there but the number of APIs seems to outstrip them and I just don’t see how many of the new APIs are going to be able to attract more than a handful of eager beavers.

While I’m all for throwing things out there and seeing what sticks, I do believe that many companies offering APIs give little thought to some of the key questions that need to be asked when considering the development of an API:

  • What’s the value to developers? Developers need some incentive to build for you. Sometimes there isn’t a financial motivation, but oftentimes there is. Given this, APIs that offer some profit motive (such as that offered by Best Buy) are probably easier to ‘sell‘ to developers than those that don’t.
  • Is an API really necessary? An API isn’t always the best solution. Companies can provide access to key data without having to create a full-blown API. In the case of Kiva, a lot of the loan data that it provides via the API could probably be provided in a simpler form, either through a reporting application Kiva develops or raw data feeds.
  • Does it make sense to entrust others with development? The thought that there are developers out there who would be eager to build great features and additions to your existing service at no cost to you is a nice one.

    But oftentimes you get what you pay for. Kiva suggests, for instance, that its new API could be used to build iPhone and Blackberry applications. That’s great, but if those would be really valuable to Kiva’s users, shouldn’t it build them? After all, Kiva knows Kiva best.

  • Are we prepared to support the API? In my opinion, open APIs aren’t all they’re cracked up to be. Developers have to be supported and by opening up access to your application and data to third parties, new risks are created. I’m familiar with a number of popular services offering APIs that have to deal big time with the performance implications of all the API requests that they process.

If more companies asked themselves these questions, I think we probably wouldn’t have the glut of APIs that we have today.

Just like everything else, APIs can be great – provided that there’s a valid business case for their use. Unfortunately I think there often isn’t and many organizations, including Kiva, would probably be doing themselves a favor by building out their own new features and services in a focused manner instead of hoping that a few good developers will do the work for them.