Orbis 2 Discussion of API’s
Software development has been identified by the Systems Criteria Evaluation Group as a key area. This document will focus on the subject of API’s as an important part of the software development environment.
API's and Why They Are Important
API: Abbreviation of application program interface, a set of routines, protocols,
and tools for building software applications. A good API makes it easier to
develop a program by providing all the building blocks. A programmer puts the
Building Block: The phrase "Change a tire" implies a long sequence of actions. It is a great convenience to be able just to say "I'm going to change the tire" without having to specify this whole sequence of actions. This idea is central to computer programming.
For example, when we write an application program that includes reading a Bibliographic record, we use a "read" function to tell the computer to read the Bib record which has a particular Orbis key. And then the record's information is returned to us.
"Change this tire" is like saying "read this record" because in both cases there are a lot of underlying details which we don't have to think about:
Take out the jack and the spare tire.
Loosen the lug nuts.
Jack up the car.
Take the old tire off.
Put the new tire on….
This read function is an example of the "building blocks" in the opening definition. It is a tool which is very useful because it allows the programmer to work at a higher level of abstraction, so that he or she is freed from any concern with the underlying minutiae. A good API will consist of a well-chosen set of useful tools like this.
Another way of defining API:a toolkit that facilitates programming tasks by presenting a higher level of abstraction to the programmer.
Why is this important to the Library?:
There are three basic reasons why we should care about a vendor’s API:
1) As an indicator of the present and future quality of the product.
Like the architecture of a software system, a good API is an indication both of the current quality of the system and the ease with which this quality can be carried into the future. Knowing that a vendor has developed, and internally uses a good API in the course of developing and evolving the system provides an extra assurance that the system was carefully designed, and that changes and additions to the software can be done efficiently and with less vulnerability to error.
Like a good architectural design, a good API is not created as an afterthought after the software has been written, but rather conceived as a result of the design, and created throughout the development process.
Orbis 2 Discussion of API’s
2) As a gateway to any open services the system may offer.
One of the things we will see more of as computer interoperability increases is the role of the API in facilitating communication between clients and servers running on different computers. "Server" here means a program running as part of the system, and whose job it is to receive and process a pre-determined set of requests from other programs.
In other words, it provides services. This involves the relationship between an API and the underlying software architecture --- architecture as "…organization of software into subsystems, interconnected through interfaces…". When these interfaces are documented and made available, they become part of the API. Any services these subsystems provide become open services. They are available to programs outside of the system.
An example might be establishing an e-commerce relationship (or part of one) between the acquisitions department and its vendors – to include a process, for example,to improve the way that vendors’ invoices are entered into our system.
A good API may mean not only that the vendor provides building blocks to help us to develop an e-commerce application locally, but that as a result of the architectural design there may actually be an e-commerce "engine" running as a server.. In this case, the service could be accessed by a program developed locally, by the vendor, or even by a third party.
3) As an important aid to any development we may do here.
If it were the case that Orbis 2 could, for as long as we use it, do everything we want, then the question of API's as an aid to local development would be moot. There would be no need to write programs to extend Orbis 2 if it already had all the functionality we could possibly want.
Although it is difficult to predict what the level of Orbis 2 development will be, it is probably safe to assume that there will need to be at least some.
Do we currently use an API with Orbis?
In the years following the installation of NOTIS, the programming group in effect wrote its own API. It exists in the form of a library of functions (routines) written in the C language, over the years.
It has constantly been added to, fine tuned and converted to adapt to NOTIS upgrades.
Creating and maintaining our own API has been a significant effort.
The best way to explain the importance of a good API may be to describe some of the things we have done with our current system, Orbis, to serve as indications to possible future efforts.
Several years ago the programming group extended Orbis by enhancing the Course Reserves Module.
When we upgraded to Notis 6.5 , the complete change in the file structure for items occasioned a near-total re-write of this module.
This re-write illustrates two relevant "It-would-have-been-nice-to-have-an-API" lessons:
- Before activating an item to Course Reserves, we have to check that it is not currently charged. It would have been nice to have an API that included an "IsItCharged?" function, updated as necessary with every version, because with version 6.5 our own function no longer worked.
Orbis 2 Discussion of API’s
We had to figure out from the new file layouts a new way to go about determining if an item is charged, and it was much more involved than before. It would have been nice if the vendor had done that for us, and a vendor that provides APIs would do that for us.
- In order to create automatic rush recalls, it was necessary to reverse engineer the manual process to see exactly which files had to be updated and how. Otherwise the integrity of the data would be lost. This proved to be time-consuming, and it would have been nice to have a an API that included an "AddRushRecall" function.
So, even though it will be easier to access the data in Orbis 2 than it is in Orbis, basing our development on working without an API and accessing the data directly would cause:
And writing our own API, as was done for Orbis:
Is "API" ever used in a larger sense? Is it really only for programmers?
The context for this discussion is the selection of an LMS system to replace ORBIS, and we are trying to evaluate the responses of the candidate vendors. Some of them have used the API/Development section of their responses as an opportunity to discuss not only APIs, but various ways staff users can access the database, such as SQL query tools and reporting tools. These are, of course, important but are not strictly relevant in a discussion about API’s.
How do you judge the relative merits of an API?
Some of the factors to consider in determining whether one API is better than an other:
So that information can be easily found, and the intended use is always clear. And, again, as an indication that the application itself was well-designed.
Both in terms of:
- covering all the general areas such as communications, importing, emulating internal functions, etc.
- having a useful set of tools in each of these areas