Most libraries today rely on many different software applications and content services to support their internal operations and their services to patrons. Smaller libraries may deal with a handful of these platforms, while larger ones tend to be involved with dozens or hundreds, often with overlapping spheres of functionality or data. Such a matrix of interrelated products and services brings considerable complexity as libraries manage each separately, while attempting to fit them into a coherent technology strategy.
In dealing with these multiple and diverse services, libraries benefit from any technologies or mechanisms that can be used to make them work together effectively and to exploit their capabilities to meet local concerns. One of these mechanisms comes in the form of APIs. The increasing availability of APIs among the major applications used by libraries represents an important advancement in technology with many potential benefits.
API Basics
Even those without a deep technical background should become familiar with the concept of the API. Technology products or services must have interfaces in order to perform their intended purpose. The ones that initially come to mind are the user interfaces that allow people to interact with the application. User interfaces can take the form of a graphical application that runs on a laptop or desktop computer, an app used from a mobile device, or an interface accessed through a web browser. User interfaces can be offered to accommodate many different kinds of computing devices and should be designed to be easily understood and operated by people. User experience experts focus on these issues.
The other kind of interface for a computer application isn’t meant to be accessed by people directly, but by other computers. APIs allow an application to accept requests issued by program scripts or other computer systems and return responses, resulting in some meaningful action. The technical implementation of these APIs takes various forms, but the general idea is to enable a computer application to provide access to units of functionality or data in a behind-the-scenes manner in addition to the bundled user interfaces.
Technical Flavors
Two of the most common ways to implement APIs include simple object access protocol (SOAP) and representational state transfer (REST). SOAP provides a messaging framework to structure and transmit service requests and responses. This protocol is comprised of several layers of technical protocols and tends to find use in complex applications. REST provides an alternative method for service requests and responses, relying on the fundamental protocols and conventions of the web, such as representing resources through unique uniform resource identifiers (URIs), using methods associated with the HTTP protocol and packaging data in HTML, XML, or JSON. These RESTful APIs have come to be more favored in the library arena.
Exposing an API
To offer an API, the creator of an application or service must develop additional programming to handle requests from external sources. The application needs to be equipped with a responder that constantly listens for requests, performs any needed authentication and security measures, parses the request, and returns a response. The API would consist of a specific set of directives, parameters, or data elements that can be accepted in a request, along with the responses that can be expected to be returned.
In order to be useful, the creator of the application must produce documentation that states all of the supported request directives, the technical details about how they must be submitted; the qualifiers or parameters that can be provided; and the structure of the response, error codes, and other relevant information. The documentation of the API must provide programmers or integrators with the information needed to be able to take advantage of the service.
Regulating Access
Just as you would expect a user interface to require a username and password or other credentials before providing access to sensitive data, APIs must have at least the same level of authentication and authorization. In library applications, there may be some APIs that might allow an anonymous agent to submit a query and receive results similar to that of an online catalog search that allows open and unauthenticated access. Data such as financial or personal details, however, must be controlled just as rigorously when accessed via an API as through the standard user interface. The control of an API can take place on multiple levels. Developers that write scripts or software to access the API may need to make use of an authorization key that verifies that they are authorized to gain programmatic access to the system. Added layers of authentication and authorization may be needed for service requests involving specific sets of functionality or classes of data. Any procedures on how to obtain authorization keys or other credentials will be specified in the documentation of the API.
It is also important to know the business terms that apply to the use of an API. Access to an API may be considered within the base cost of a product or additional fees may apply. Whether third parties beyond the library can gain access to the system through the APIs may also be an issue, especially if the third party needs to exchange data with partners outside of its own organization.
It is common for a vendor to offer a software development kit (SDK) to other organizations that might want to develop their own applications that depend on the APIs of a business system. The developer of an ILS, for example, might offer an SDK to developers interested in creating add-on modules such as inbound or outbound messaging systems for library notices. This requires access to internal functionality that may not fall within the standard protocols such as session initiation protocol (SIP) or NISO (National Information Standards Organization) circulation interchange protocol (NCIP). A third-party developer may be asked to pay a fee or to share a portion of commercial revenues to gain access to the SDK and receive technical support.
Support Issues
Other factors come into play as a library makes use of the APIs of its core applications. Special considerations apply when the API has the ability to create or modify data within the system. Some providers require that the library attends special training in the use of the API in order to ensure that any scripts or software created do no harm. A vendor will take responsibility for data corruption issues when accessed through the user interfaces that it created to be packaged with the system, but it may exclude from normal support any incidents related to when things go awry with a script created by the library. Special fees often apply to support issues related to the APIs. Use of APIs often falls in the “use at your own risk” category, but with care and adequate testing, APIs can be employed quite safely.
An Area of Differentiation
The breadth of an API may vary from those that support only a narrow set of requests to those that address all the functionality and data available. If the library plans on taking advantage of the API for a product or service that it is considering, it should review the documentation in order to evaluate whether the API supports all of the capabilities it expects. In scenarios where libraries have significant needs for interoperability, detailed customized data reporting, or local functional requirements, the capability of an API can be an important area of differentiation among the various products or services under consideration.
Following the service-oriented architecture, many applications are themselves primarily constructed out of an API of lower-level services. User interfaces and other system components are composed by assembling these smaller units of functionality. For systems based on service-oriented architecture, some or all of the services used internally can be exposed externally as an API.
Consuming APIs
Libraries benefit from APIs when they are able to perform tasks that are not possible through the bundled user interfaces or that automate tasks that otherwise might be performed through manual or batch processes. They can make use of the APIs in many different ways, ranging from simple scripts that extract data for reports to full-blown software applications that perform a variety of related functions, but remain dependent on the core application.
One method of accessing an API involves creating scripts, or small computer programs, written in languages such as Perl, PHP, Python, or Ruby on Rails. These scripting languages can be easily mastered by a library programmer without extensive coursework and training. Taking advantage of the API requires proficiency with a programming language, its methods for interacting with web services, and the specific directives supported by the API. While each of these layers may take some study and practice, those with even modest technical skills or aptitude should be able to create useful scripts fairly quickly.
The language in which the vendor created the application has no bearing on the programming language a library might use to access the API. Such details as whether a business application has been created in Java, or C++, or other programming language; its underlying database engine; and other technical components don’t matter. The requests and responses defined in the API operate at a level of abstraction, separate from the internal components of an application.
Interacting with an API involves significantly less complexity compared to developing full-featured business applications. The creation of a business application such as an ILS usually involves teams of software engineers, designers, quality assurance and other professionals able to work with a complex set of source code modules that may be comprised of millions of lines of programming code written in languages such as Java or C++. Exploiting the capabilities of a robust API enables libraries to create new services or local features with much less complexity than working with the deep code of an application such as an ILS.
Development Communities
Large-scale applications such as ILSs or library services platforms that offer APIs are implemented by many different libraries. While some libraries have unique scenarios, there may be many scripts created that exploit the API of a system that would be of use to other libraries with related projects. It is a common practice for libraries to share these scripts to avoid redundant efforts.
Taking the practice of sharing code that uses an API a step further, more organized development communities have formed that take a more systematic approach to efforts surrounding the programming developed that interacts with the API of a given product. While some of these communities come out of informal arrangements among libraries that happen to use the same system, others have been launched through initiatives of the vendor. Having a development community engaged with its products and services can mutually benefit both the vendor and its customers. Such a development community helps library programmers become more self-sufficient as they work with the APIs of a system and less reliant on the vendor. Some vendors dedicate resources such as sandbox servers where libraries can develop and test their codes without having to put their production systems at risk, repositories where code can be deposited and shared, and events where programmers can work together on projects.
An Emerging API Ecosystem
As the number of major applications that find use among libraries proliferates and as more of the vendors offer APIs, opportunities arise to enable them to work together in beneficial ways. Rather than considering each system as isolated and self-enclosed relative to how data flows in and out, the use of APIs opens the possibility for more dynamic interactions that are beneficial both in terms of more efficient operations behind the scenes and a more elegant presentation to patrons.
Some of the applications that might be considered within a potential framework of interoperable APIs might include ILSs, discovery services, ebook lending platforms, learning management systems, accounting systems of the library’s parent organization, ecommerce systems, and the online ordering platforms of suppliers. Technical relationships among these kinds of applications aren’t necessarily new. Libraries have developed various ad hoc ways to move data around these systems through importing and exporting data files in batches. The use of APIs could enable more automated interactions that happen more efficiently and with immediate effect.
The availability of APIs across the multiple platforms upon which a library relies to provide content or services carries the potential to enable a more unified presentation to its users. Many libraries offer discrete selections from their websites such as those for their local catalogs, to services related to ebook lending, to different databases of electronic content, and many others. In its simplest form, a library website might provide links to the native user interfaces of each of these services. This nonintegrated, though commonly employed, method essentially hands users over to different interfaces that look and are operated differently depending on the selection made on the website. By taking advantage of the integration opportunities when these multiple services expose APIs, it becomes more possible to craft a web presence that retains library users within a more unified interface that blends content and services powered by multiple sources behind the scenes.
This integration can be accomplished in different ways. The library may make use of its own programmers that work with the APIs of multiple underlying systems to integrate content or services into a higher level user interface, such as a library website based on Drupal or another CMS with similar capabilities to extend programmatically. Many libraries work with discovery interfaces such as Blacklight or VuFind to blend content from multiple discovery services with that of their local catalogs.
Another integration strategy depends on cooperation between vendors that have common library customers. In one scenario that has seen multiple implementations in the last year or so, the result is a more integrated experience for lending ebooks. The vendor of an ILS or discovery service works with the developer of an ebook lending platform in order to allow library patrons to discover, select, and borrow ebooks through the library’s main online catalog rather than having to use one interface for print materials and another for ebooks. This integration is made possible through the APIs that have been enabled by ebook lending platforms such as those from OverDrive, 3M Cloud Library, and Baker & Taylor, which can all be tapped by the online catalog vendors. The integration between online catalogs and ebook platforms has come about in large part due to the demand by libraries for improved patron experience for ebook lending as articulated through the ReadersFirst initiative. The blending of ebook lending with the online catalog has become an increasingly common expectation for libraries, instantiated across multiple partnerships between discovery or ILS developers and the major ebook providers.
APIs provide an important technical mechanism for integration, interoperability, and the extension of functionality. Many possibilities remain within the library environment where specialized content or service activities currently delivered through disparate interfaces could potentially be brought together in a more user-friendly way via integration into the prevailing interface of the library’s web presence. With the increasing availability of APIs, libraries no longer have to be satisfied with using their websites to deliver their users to external service providers. Instead, there are increasing opportunities to create a more sophisticated and integrated web presence able to fulfill patrons’ information needs while strengthening awareness of and engagement with the library.
