Done for 2021

Updated:

The final four API “refactorings” (for this year) are now published online. Unlike the previously provided ones, they affect service level agreements and desired evolution qualities rather than the endpoint design and the message structures (for the most part):

API providers and customers are often in opposing positions when making decisions about API longevity and development. For example, providers might want to increase their customer base while at the same time minimizing the number of different versions they have to run and maintain in production. An individual customer whose use case is covered by the API may not want to be forced to upgrade to new API versions. In such cases, it helps if the provider clearly states their API guarantees. If they have to be adjusted, advice can be found in our new Tighten Evolution Strategy and Relax Evolution Strategy refactorings.

One possible outcome could be that the API will be offered in several versions, with the provider introducing an explicit Version Identifier so that clients can choose which version to use. Depending on API changes, introducing a Version Mediator can (temporarily) hide API changes from clients by introducing a mediator that maps the old API calls and their request- and response messages to new ones.