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.
The APIs available today are far more sophisticated and capable of managing much larger and more complex data structures. In the lab, we need to handle increasing quantities of data from multiple projects and instruments. This has led to the implementation of more modern ways of transferring data from devices, computers, and data repositories using web services. These are typically set up as RESTful services which use HTTP for transferring messages that are in a format such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML). This is the most common web service style that we find within our industry, although gRPC is becoming increasingly popular due to the inherent bi-directional communication that it offers, providing a far better form of integration in many cases.
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.