Although it started out as a programming term, application programming interfaces, or APIs, have become something of a catch-all for how instruments and systems communicate with each other.
All the instruments within a lab that can be automated have an interface that makes cross-communication possible. APIs today use a variety of languages and methods to communicate. With each communication method, there’s a different way to tell an instrument to do something, such as to start measuring a sample plate on a plate reader.
The first APIs that were developed were very simple and could only move small amounts of data at any given time. In the early days of APIs, that was OK because there was not much data to move around and what little there was proved quite costly to move.
Today, APIs are easy to implement, and once they are in place, they generally work smoothly. If updates or modifications are needed, instrument vendors can handle these quickly with little interruption to customers’ workflows.
Given their prevalence, it’s important to understand what constitutes a good API. The first characteristic is that it must be well documented with examples of how to use it. Currently, there are efforts in the industry to capture all that information in a central repository led by the Pistoia Alliance, a global nonprofit organization focused on pre-competitive collaborations.
Other hallmarks of a good API include reliability — meaning it should work every time it is used — and the ability to handle errors when they occur and help the lab recover quickly and efficiently. APIs should also accurately represent the behavior of the instrument. For example, a command to run a plate reader should do just that when it is invoked. Bad APIs are the exact opposite: these usually have little to no documentation, poor abstraction, commands that don’t result in the expected behavior, and inconsistent handling of errors.
One of the current challenges for the programming community is developing an API that can work consistently across different instruments. A portable API would simplify things for system integrators and customers and would help to lower the costs of adoption. Several efforts are underway to try to come up with a standardized language for APIs. Biosero is currently involved in the Standardization in Laboratory Automation initiative — SiLA, a nonprofit consortium that provides a framework for integrating and sharing laboratory data. Standardized APIs are still some ways away from the field as a whole, but there has been significant progress.
At Biosero, we continue to push the use of standards where applicable to help our customers, instrumentation vendors, and all users of laboratory automation. Establishing consistent standards for robust APIs ensures that instruments can be integrated seamlessly and reliably as part of automated workflows within the laboratory. Better APIs lead to less instrument downtime, more data capture, enhanced productivity, and longer walk-away times for scientists leveraging automation to accelerate their discoveries.