Application program interfaces (APIs) have changed the face of application development. By expressing software components in terms of their operations, inputs, outputs and underlying types, APIs provide developers with building blocks they can draw on to more rapidly and efficiently create applications.
But the increasing adoption of APIs and their growing business value also means API providers and developers are facing new obstacles. Providers are deprecating and versioning their APIs as their needs and business priorities shift, and this can create tension with developers who have to deal with the consequences. If a key part of your business is built around an API provided by a company like Facebook or Google, and that API breaks or is discontinued, it can be a serious headache.
How to minimize exposure to API risks
Both providers and developers can adopt key strategies that will minimize the business risks that accompany API modifications, says Brian Pontarelli, CEO of Inversoft, which provides content filtering, user management and community services to companies like Disney and the NFL via APIs.
"We put ourselves right smack in the middle of the API economy," Pontarelli says. "We built APIs to help customers moderate and manage their users. As more and more people were looking at these web-based APIs, we realized it was becoming more and more important to keep up with standards and keep our APIs as modern as possible."
"We started off with a fairly Web service-style API based on SOAP," Pontarelli adds. "Then we moved to a more RESTful, JSON-based API. It took years to go through that transition. Our customers are enterprise companies and they don't move as quickly as startups. It's really important not to break their existing tools."
Pontarelli says one of the key best practices Inversoft has implemented is the use of semantic versioning (or SemVer) across the board, with all software and APIs.
"It helps customers understand when a new version is coming out whether it's going to be compatible," he says. "These version numbers mean that things are compatible, these version numbers mean it's not compatible."
That works hand-in-hand with a road map and product plan designed with the pain of API deprecation in mind.
"I think one of the biggest things to really factor into it is to try to work with the vendors to understand the roadmap and product plan," Pontarelli says. "We try to do feature upgrades with API compatibility four to six times a year. We break our API compatibility once every two years."
How CIOs should approach APIs
CIOs who stay aware of that schedule and sync to it tend to do fine, Pontarelli says.
Sign up for CIO Asia eNewsletters.