Application Program Interfaces: What You Need to Know About Your Data

What is an application program interface (API)? According to Wikipedia, an API is "a set of routine definitions, protocols and tools for building software and applications." In the case of transit, distinct systems such as scheduling, automatic vehicle locating, electronic fare collection, computer-aided dispatch, automatic passenger counting, ticket vending machines and maintenance management systems use APIs to exchange information.

First, APIs are not complicated. These simple programs are used to exchange information between systems or to communicate between servers and browsers. For example, an electronic fare collection system needs APIs for selling fare products and real-time validation as passenger boardings. APIs are typically based on XML or JSON. Both of these data transfer formats are easy for humans to read and write and easy for machines to parse and generate. In fact, code for parsing and generating XML and JSON data is readily available in many programming languages.

Second, APIs should not be expensive. These are simple programs, not complicated beasts. Unless you have asked for changes, maintenance is not required except for the occasional system update. It’s your data; you have the right to share it and there should be no usage fees.

Third, APIs may be proprietary because the provider of the API is taking information from their (your) database and making it available to third parties. By nature, an API is a custom protocol that allows different systems to communicate with each other. However, the API is what makes a proprietary system open.

A transit agency should not include language in an RFP similar to: "No proprietary or custom designed protocols shall be used." Instead, you should include language that "proprietary APIs and custom-designed protocols shall be openly published, documented and based upon a standard protocol, such as XML or JSON."

Fourth, you have a right to your data. Be aware that your system suppliers may use APIs as leverage. The holder of the API has the ability to set the price, control access and limit your options. You purchased the system and you have a right to your data.

APIs are critical to your success and keeping control is a step toward increased flexibility down the road. APIs provide an open architecture that supports vendor independence and streamlines integration. Choice creates competition and competition serves you and your riders.

Try to avoid putting your agency in a position of being stuck with a particular vendor. Make sure a level playing field is established from the start by requiring open APIs with their interface control document (ICD). If you feel you do not have the choice of going to another vendor, negotiate directly with your current vendor. Buy direct, and keep control of the information you have already payed for, eliminating other markups and usage fees. Enjoy the freedom of working with the best solution provider for you.

Fifth, open standards are available thanks to the efforts of Google and the SIRI initiative. GTFS-realtime supports trip updates, service alerts and vehicle location in real time, allowing updates to users that enhance their experience of your transit services. GTFS-SUM seeks to provide the next generation of shared use mobility software, facilitating awareness of and access to car share, bike share, rideshare/carpool, shuttle and mass transit options.

Service Interface for Real Time Information (SIRI) specifies a standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

More can be done. Transit agencies should be able to change their payment gateway, POS system, maintenance management system and other systems seamlessly. Standards can and need to be developed for interfacing between central systems components. This is a great role for the American Public Transportation Association (APTA) to fill.

In 2017, with the Internet of Things (IoT) driving the open interface revolution, the time has come for Intelligent Transit System providers to provide open APIs.

The key takeaway is to make the most of your data by staying in control. Talk with your existing provider or change to a provider who recognizes the open interface revolution. Finally, take the time to plan before you purchase. The bottom line should be a modular, flexible and expandable vendor resulting in lower cost for you and more convenience for your passengers.

Stan Craft is a system architect with Init. Init’s solutions feature an open architecture approach that supports vendor independence and streamlines integration with other systems. Our modular and open approach to ITS requirements allows your systems to be more easily managed. Init delivers software and hardware solutions that offer you complete flexibility for any transit requirement — now, or for the future.