A good example of the benefits of API betas can be seen in Microsoft's current beta of its Office 365 unified API. The API, which is designed to give developers access to multiple Microsoft cloud services APIs through a single REST API endpoint, was unveiled earlier this year and since that time, developers have been able to experiment with the API.
Their usage and feedback has enabled the Redmond software giant to make changes and improvements, often at a rapid pace. For instance, earlier this month, Microsoft announced a set of breaking changes to the Groups API accessed through the unified API. The breaking change was introduced the same day the announcement was made.
This past week, Microsoft announced another set of significant breaking changes to its unified API beta, giving developers advance warning of just two days to update their apps.
The Flexibility to Change
Rolling out breaking changes on short or no notice is, of course, all but impossible for a major API provider, but it's entirely acceptable as part of a beta like the one Microsoft is running for its new unified API. What's more: it's entirely expected because one of the primary purposes of a beta roll-out is to gather data and solicit suggestions from real developers who are building real apps.
Developers who participate in a beta expect changes, and get rewarded in two ways for putting up with them. First, early access to an API allows them to get a head start on building apps that will use those APIs. Second, betas give them the opportunity to influence the final API that is launched into development.
No matter how capable and thoughtful an API provider's internal team is, there's no substitute for real-world feedback from the third-party developers and beta APIs give API providers the ability to get that feedback and act on it in a manner not possible in production.
Betas Help Avoid Breaking Change Headaches in Production
Using a beta to thoroughly test an API, get developer feedback, and rapidly iterate is important because once an API goes into production, breaking changes that require developers to update their apps can create significant headaches.
In some cases, breaking changes require developers to make significant modifications to their code. When such modifications are made to production apps, developers not only need to address the code. They need to test and perform QA. For mobile apps distributed through an app store, developers may need to submit new versions, which necessitates going through app store approval processes that are not always easy or expeditious.
Even providers of some of the most popular APIs have found themselves facing the ire of developers for breaking changes. Facebook, for instance, once promised to break things only four times a year after being named the most problematic API in a developer survey. While its suite of APIs still evolves at a rapid pace, creating challenges for some developers, the company today is making an effort to better balance its needs with those of developers.
But developers aren't the only ones who suffer when APIs break. If developers don't address the breaking changes in time, which sometimes occurs because they aren't monitoring for API changes, it can create poor experiences for the end users who ultimately rely on their API-powered apps. Those poor experiences can translate into end user dissatisfaction, which can result in lost revenue and harm to the API provider's brand.
Obviously, most API providers will at some point or another have a legitimate need to introduce breaking changes. But a thoughtfully designed and well-executed beta can help API providers identify problematic API functionality and functionality that could be implemented better, significantly reducing the risk of launching an API that will require avoidable breaking changes in production and more API providers should explore how they can take advantage of betas to build better, more stable APIs.