Continuous API Management

Chapter 5. Continuous API Improvement

It is not necessary to change. Survival is not mandatory.

W. Edwards Deming

In the previous chapter we introduced the API lifecycle and defined ten pillars of work that you’ll need to focus on. The lifecycle and its ten pillars define the work that you’ll need to do for your first API release. The pillars are also needed for all the changes you’ll make during the lifetime of your published API. Managing changes to APIs turns out to be a critical element of an API management strategy.

Changing your API can have a big impact on your software, products, and user experiences. Shipping a code change that breaks an API can also have a disastrous ripple effect on all the components that use it. Changes that don’t break the API can cause big problems if they alter an interface in some unexpected way. API products can produce a complicated nest of dependencies. All this makes change management an important API management consideration.

If you never had to change them, managing your published APIs would be a pretty simple task. But of course, change is an inevitable part of an API in active use. At some point you’ll need to fix a bug, improve the developer experience, or optimize the implementation code. Performing these tasks requires intrusive changes to your deployed API.

The job of managing API changes is made more difficult by its large scope. An API product isn’t just an interface. Instead, it is a collection of many pieces: interfaces, code, ...