{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

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.

Patricio Robles

Published 5 February, 2009 by Patricio Robles

Patricio Robles is a tech reporter at Econsultancy. Follow him on Twitter.

2377 more posts from this author

Comments (3)

Avatar-blank-50x50

Rob Knight

There may be plenty of developers out there but the number of APIs seems to outstrip them

This isn't strictly true though.  I know it's meant as hyperbole (you probably don't believe that there are actually more APIs than developers), but even as hyperbole it's wrong.

The whole point of creating these kinds of APIs is to enable unknown possibilities, to enable people to use your service in ways that you haven't thought of yourself.  Since no individual or organisation can feasibly keep on top of every possible use of their technology, creating an API is a good way of finding out how else that technology could be used.  It's a classic example of information and resource allocation problems, in that the business operating the services has the resources (the system they've developed) whilst others have the information (ideas about how it could be used); the API eliminates the barrier to sharing those things.

In many cases, APIs begin life as part of the internal architecture of a system, perhaps something that enables the front-end system (resposible for rendering content in HTML for consumption by web-browsers) with the back-end system (responsible for business logic and data).  Making an API public is just a question of allowing open access to the back end system, albeit with some security and abuse controls in place.  It's often not that much effort to do once you have an internal API in place.

over 7 years ago

Avatar-blank-50x50

skylar

A very interesting perspective.

As Rob points out, the Kiva API is an important starting point for Kiva doing its own development. We started doing a couple of map-related features (see Map View on the lender page and http://kiva.org/kivavision) and both of these require publicly accessible data APIs accessible by JavaScript.  RSS feeds are really just a transformation of the XML output of the API so clean up of our RSS (a simpler data feed?) also starts with a well-designed API.  And it is true, our public RESTful interface belies the programmatic API we're developing for ourselves to make it easier to write new features.

To us, the most important aspect of the API is the way it allows volunteers to be involved. We are a non-profit with very limited resources. Kiva is an organization that relies heavily on the enthusiasm and passion of people to get involved. All of our loan profiles are edited or translated by a network of hundreds of volunteers. Our field partners are trained, audited, and assisted by another network of hundreds of Kiva Fellows. In the office, we probably have anywhere from 8-15 volunteer staff helping us to facilitate loans in the developing world.  Sometimes, those volunteers are engineers, but it's very difficult to have them working in the depths of our code base.  The smartest thing often times is to have a sandbox for these volunteers to work – one that, for example, prevents someone from accidently exposing private lender data.  So, that sandbox is this API. Many Kiva features are built by volunteers (Kivavision, the original Lender Pages feature, etc.). The API facilitates volunteers.

One final point Rob didn't cover is that APIs are critical to working with partners. You could taylor an interface to working with one partner (corporations do this all the time and get caught up in supporting many expensive one-off programmatic interfaces), or you could create one general, self-service interface that lets non-partners work too. This means both Google and someone in an apartment on the outskirts of Chicago have equal opportunity to work with Kiva. We have lots of partners interested in working with us this way, and many of our users have asked for a RESTful API to Kiva (similar to asking for an iPhone app or a notification system).

Thus, having a clear need for an API, the last question to ask is, does it make sense to build a developer destination and foster a public development community? While not free, I'd say documentation and community features have been the easiest and cheapest to put in place. Furthermore, Kiva is committed to being a fully transparent organization, and as a non-profit, we see our our resources as something belonging by the greater good of the community. Therefore, it would seem irresponsible of us to not document the API and make it available to everyone.

The four questions you ask are great points for consideration. We certainly struggled over each of these and others in committing to and planning the Kiva API. I would recommend that any other organization considering a public API do the same. Our determination is that the Kiva API is in the best interest of our lenders, donors, partners, and volunteers. We might be wrong, but it is a calculated risk we're excited about taking.

In the meantime, we'll do our best to be buoyant, keeping developers afloat in the sea of API glut.

over 7 years ago

Avatar-blank-50x50

Mark Rock

An article from econsultancy about trying to hold back API's is a bit like a newspaper 5 years ago complaining about too many blogs or a broadcaster 15 years ago complaining about too many channels.

It doesn't matter.

Most good applications these days are written using private API's anyway. Ours are. If these are opened up to a wider community what is the risk. If there is no risk either use them or ignore them.

Simple as that

over 7 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.