![]() ![]() The former is the primary building block of your API and the latter reveals why versioning is needed. What this boils down to, in the nitty gritty, is managing data contracts and breaking changes. You are delivering data to the public in some fashion and you need to communicate when you change the way that data is delivered. Versioning is effective communication around changes to your API, so consumers know what to expect from it. Here's our working definition: API versioning is the practice of transparently managing changes to your API. We should start with level-setting on what is meant by the term "API versioning". We're going to assume a REST API context, as it's a standard for many APIs, and focus on the versioning aspect. This article seeks to highlight those reasons for versioning and strategies for accomplishing it. However, I have found that most developers-including myself, until I learned some lessons the hard way-are not aware of these reasons and strategies. There are clear reasons why your API needs to have versioning, and there are clear strategies for how to effectively navigate API changes. And we should not just make a second version of an endpoint when the first no longer seems to suffice. It's not always clear as to what v1 or v2 is referring to. These questions around versioning are not easy to answer. # What catalyzed the change between v1 and v2? How are they different? If you are a maintainer of an API, you might also be fussing about trying to field challenging questions like these: # Is this version 2 of just products or of the entire API? If you've been burned by API changes, you're probably the one fussing. If you're not very familiar with APIs, you might be wondering.why all the fuss about API versioning?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |