Why CIOs need to plan for API deprecation
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.
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.
[ Related: 9 predictions for the future of programming ]
"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.
[ Related: What Microsoft's new developer strategy means for CIOs ]
"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."
CIOs who stay aware of that schedule and sync to it tend to do fine, Pontarelli says.
"Honestly as long as the CIO is thinking in terms of budgeting for upgrades, they're going to be in a good position," he says. "If you're staying current, the pain of a deprecation is going to be less than if you're years behind. It takes communication and planning. I think that's key to any relationship between a vendor and a company."
That said, he notes that it's also essential as a vendor to assess how API changes will affect customers. If an API change is going to break the API for a majority of customers, especially enterprise customers that move less quickly than smaller companies, Inversoft seeks to provide a compatibility layer to ease the transition.
"Almost every time we've done a major API overhaul, we've put in some compatibility for large customers that are going to feel the greatest pain," Pontarelli says. "Do they have the development staff in place to do an upgrade Can they stay on an older version at least until they can get it into their product plan We can support them on an older version for 16 to 18 months."
[ Related: Can citizen developers bring shadow IT into the light ]
Smaller companies, on the other hand, tend to push for a faster rate of change.
"We have a number of smaller customers," he says. "We tend to find the developers in those situations are often pushing us to move even farther ahead than we would like. Sometimes we need to push back and make sure something is really going to be a thing in the industry before we jump on board."