Today’s episode is sponsored by the rain in Amsterdam and werewolves. It’s my second trip here within last two weeks with the initial goal of attending AWS trainings and some sightseeing, but AWS canceled one of these a day after my company bought non-refundable plane tickets and booked the hotel, so… more emphasis on sightseeing, or rather sitting in the coffee shop waiting for better weather. Why werewolves? Well, because in this installment of our long-running series on API design, we will talk about versioning and I find the werewolf a decent allegory to represent breaking (or tearing) changes in API that leads to a dilemma: which versioning strategy should be employed. And because I like fantasy themes for my articles.
Image by Aleksandr Nikonov
There are many approaches to versioning with pros and cons and it’s difficult to definitively choose one or the other. We will explore possibilities of how to version and, where to actually put the version information, including URI, parameters, content negotiation, custom headers, or… nowhere at all. We are going to talk about breaking and non-breaking changes and various considerations and hints relevant to helping clients of your API deal with the evolution of our system in a bearable way.
Before we start to multiply API version, we should consider whether we really need it. Backward compatible, or non-breaking changes should not Read the rest of this entry »