Non-breaking API changes
Learn about helping others to handle your version of software, compatible API changes, HTTP for connection handshaking, breaking network agreements and and safe 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 ...