Summary

In this chapter, we explored the challenges of modifying APIs once they’re placed into production. We reviewed the principles that govern changes to production APIs: first, do no harm, forking the API, and knowing when to say no. We also covered the three rules of designing and implementing API updates: take nothing away, don’t redefine things, and make additions optional. We also discussed the importance of continuing to use existing tests to confirm that our updates don’t break any current API consumers, as well as discussed new, standalone tests for the added features of our updated API.

We spent time on the set of tasks needed to properly deploy API updates into production, including supporting reversibility, using side-by-side deployment, and the challenges of employing the overwriting release tactic. Finally, we reviewed the issues we need to address when shutting down a production API, such as communicating the shutdown, releasing the code and/or interface for others to use, and marking our API with an HTTP 410 GONE status and response message to ensure others who encounter the original service in the future will know what happened.