If It Doesn't Have an API, It's Not Worth Having
In a soon-to-appear Library Journal column, I discuss strategies for an uncertain future. One of those strategies is the topic of this blog posting, since I wanted to both throw this out there for discussion as well as to discuss it more thoroughly than I can in an 800-word column.
First, let's define API: Application Program Interface, or simply a way for one software program to interact with another through a standard protocol. I don't mean to imply that "standard protocol" must be an actual standard, it can be a unique but documented way to interact with an application and get a structured (i.e., machine-understandable) response back (typically in XML).
This basically also describes Web 2.0. But APIs existed long before the big Web 2.0 buzz, and will exist long after it inevitably goes down to dust. So why are they so darned important?
It provides a way for you to help yourself. If you can't get traction with a software vendor to offer a new capability you can sometimes use an API to do it yourself. That is, you can write a software application that can query your system to extract various information from it to perhaps create a new service with that data (for example, in a library catalog context, perhaps a new books list).
It provides a way for others to help you. Z39.50, and SRU which is replacing it, are both APIs, and they allow all kinds of discovery services that would not be possible without them. OAI-PMH is another. These APIs allow for various information aggregation and/or discovery services to be created on your behalf.
It can shield you from software changes. At my place of employment we have written our own user interface to a commercial metasearch application, using its API. One of the benefits of this is that we are now shielded from changes in the vendor application. We can install software updates with impunity, and take advantage of new capabilities as it fits our schedule.
There are no doubt other benefits, but these are a few that immediately leap to mind and that are perfectly sufficient to make my case. A word of caution, however: not all APIs are created equal. An API is only as good as the capabilities it exposes and the quality of its documentation. Don't allow a software vendor to say simply "yes, we have an API". Ask to see the documentation and study it carefully. Are you likely to be able to accomplish a reasonable set of tasks with it? Can the vendor give you a list of customers who are presently using it so you can ask them how pleased they are with it?
In general, though, if you are in the market to license software, give those with an API a boost in your scoring. In the end it will likely be much more useful to you than many other criteria you are presently using to evaluate software.
A good API also lets other people help you by writing code against it. One question to ask a vendor about their API is "Who's used it to do something cool?" If the vendor can't produce anybody, either the API is brand-new or -- it's so horrible nobody can do anything with it.
On the other hand, if you see a half-dozen cool projects, rejoice! because you can probably get hold of the code.
And a good API allows you (or others) to mix information from various sources to create interesting new services, and on the web the mashed-up whole often exceeds the sum of its parts. Some sites like Google Maps, Amazon, Flickr, etc., have great, generally useful information that enhances all sorts of other services.
Library systems of all types should have open, public APIs, so that our users can create their own alternate interfaces and mash-ups using library information. Currently, outside people are mostly limited to accessing our information through screen scraping (like Library Elf) or through working out persistent link patterns (like Greasemonkey catalog look-ups, etc.) If our systems were more open, we might be surprised at the creativity that would be unleashed, and the new ideas for the catalog that might come from the outside world.