Late last year I received a review copy of the most recent Library Technology Reports, Opening Up Library Systems Through Web Services and SOA: Hype or Reality? written by Marshall Breeding. It's a simple report, consisting of a mere three chapters. Chapter One introduces the concept of Application Programming Interfaces (APIs), and places them in the context of the Integrated Library System (ILS). Pretty geeky stuff, but not too difficult for the layman to understand. Chapter Two is where the real meat is. Covering Ex Libris, Evergreen, The Library Corporation, Innovative Interfaces, Koha, Polaris, SirsiDynix, Talis and VTLS, "each vendor was contacted with a request to respond to a set of questions that elicit information about the APIs offered by the systems that they support."
The questions that were asked of each vendor were:
- Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products
- What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?
- Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?
- Does the API operate through REST or SOAP web services, or does it use proprietary mechanisms for transmitting data and requests?
- Can the API create and modify data, or is it read-only?
- Describe the technical architecture of the API.
- Are your APIs able to perform the following types of transactions? (several I'm not going to list)
- Describe any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.
- In what way do you consider your system one that embraces the service-oriented architecture?
- Are there any other issues regarding APIs that you would like us to be aware of as we develop this report? Are there other approaches that your company supports instead of or in addition to APIs for providing end-user access to system data and functionality?
Vendors offered significantly different amounts of information in each of their answers, but as you can guess the results are a gold-mine for anyone playing with or considering using an API for any of the above vendors.
The report then concludes with a brief chapter of observations and conclusions. I highlighted two bits I found interesting. "We also not that the two open source systems lag behind proprietary systems in terms of customer-facing APIs that result in tangible activities which extend functionality or enable interoperability. … This trend has much to do with the demographics of the libraries using the software." And, "The APIs available to library programmers continue to be quirky and less than comprehensive, even from the vendors with the strongest offerings in this area."
I found the report interesting and enlightening, and as I mentioned above, the results are a gold-mine for anyone playing with or considering using an API for any of the above vendors.