This chapter covers
- Changing an API and its impact
- Supporting multiple versions of APIs/schemas
- Avoiding breaking changes
José noticed that the change of moving from dog to pets had a knock-on affect with Max the frontend developer. If Nidhi had released the backend change before Max was ready, a large portion of the PetSitter website would have stopped working. But, because the team communicate often this was hardly a problem, and they could easily coordinate how to roll those changes out. But what will happen when the API is made public? How can those breaking changes be avoided? And if they’d made these changes after outsourcing the mobile team, how would that be handled?
In the team’s case, they have a small and easily managed API between the frontend and backend as well as between José’s team and the mobile developers, but as it grows to include more consumers (and more developers) things will get harder to manage. After they release the API to the public they won’t have that control anymore and will need to be considerate when making changes.
The team decided to look at this as an example of a breaking change and explore what sorts of actions they should take in future and if there is anything they can do ahead of time to prepare for that eventuality.