Versioning Web API
Change is an inevitable factor in the life cycle of an API. More and more organizations today face a dynamic and changing environment. The change is driven by factors within the enterprise like implement a new business model, expand to a new market. It can also be external such as disruptive technologies, new government regulations, changes happen in partner/consumer organization, etc. I will talk about versioning in general and versioning Web API using multiple versioning strategies in detail in this post.
Challenges – Evolving API
Handling changes in software systems is not an easy task and it is more challenging particularly in loosely coupled distributed systems, such as APIs or Microservices. When you make changes to the API, consumer should be able to continue using the API like they were using before.
It is unreasonable to force all consumers to adapt or update their apps to access the latest version of the API. The API provider doesn’t know about the consumer’s implementation that use the API and the components rely on it.
A small change is enough to break some of the clients consuming the API. A change is considered as breaking, if the behavior of an existing API is changed in a way such that clients using that feature might not work anymore. Though we can categorize the changes as breaking and non-breaking, it varies depend on the implementation by the consumer.
Please check the following link for more details. It includes the sample code in Github