Non-breaking API changes

Minimizing work transference to other teams

We now know how to design applications so that they can be deployed easily and repeatedly. That means we also have the ability to change the way our software talks with the rest of the world easily and repeatedly. However, as we make changes to add features, we need to be careful not to break consuming applications. Whenever we do that, we force other teams to do more work in order to get it running again. Something is definitely wrong if our team creates work for several other teams! It’s better for everyone if we do some extra work on our end to maintain compatibility rather than pushing migration costs out onto other teams. This chapter looks at how your software can be a good citizen.

Help others handle your versions

It won’t come as a surprise to learn that different consumers of our service have different goals and needs. Each consuming application has its own development team that operates on its own schedule. If we want others to respect our autonomy, then we must respect theirs. That means we can’t force consumers to match our release schedule. They shouldn’t have to make a new release at the same time as ours just so we can change our API. That is especially true if we provide SaaS services across the internet, but it also holds within a single organization or across a partner channel. Trying to coordinate consumer and provider ...