API Versioning: All You Need To Know About V1/V2
If you are not versioning your REST API you should take a look at this post and learn all its benefits and how to apply it in real projects.
Introduction
Hi, Folks. Today we are going to learn about the importance of API versioning and its impact on software development & Discover best practices, strategies, and tools for effective API version management to ensure seamless integration and maintain compatibility.
Why do we need API Versioning?
For a simple API, being able to create separate versions may not be necessary. However, Let's take an example for a larger project they may have frequent & feature changes in APIs with more complex requirements, and it may be necessary to make updates.
In this case, your may need to create a new version of the API. So that both the initial version and the new version can be run in parallel.
How to do API Versioning?
In more general API versioning can be handled in a number of ways. I am going to explain three typical techniques for versioning.
URL based versioning
Header based versioning
AWS API Gateway & URI Versioning
When it comes to implementation, both techniques offer advantages and disadvantages. It all depends on your project demands and which strategy is best for you.
URL based versioning
URL-based versioning however is apparently not the best way, since it changes the URL, which violates RESTful API rules.
URL-based versioning, as the name implies, incorporates the version in the API request URL. A URL like https://example.com/api/v1/users this may appear. For API versioning, this is a simple way. The version of the API may be easily identified by glancing at the URL.
For example: Let's take a Node.js project.
In the project directory create a Routes folder. This folder will hold the separate directories that control the navigation routes to our API endpoints. Now, in this Routes folder.
We can put individual version route files directly into this folder
v1.js
v2.js
else we can create version subfolders:
v1/index.js
v2/index.js
http://www.example.com/api/v1/products
http://api.example.com/v2/products
So, Now you can change the URL version number to check the new features or business logic implemented on backend servers.
Query Params
This type of versioning adds a query param to the request that indicates the version. It is very flexible in terms of requesting the version of the resource.
http://www.example.com/api/products?version=1
http://www.example.com/api/products?version=2
But, It has the disadvantage of out-of-sync issues between multiple versions of API.
Header based versioning
The header approach is one that provides more granularity in serving up the requested version of any given resource.
Accept-version: v1
Accept-version: v2
A custom header (e.g. Accept-version) allows you to preserve your URIs between versions though it is effectively a duplicate of the content negotiation behavior implemented by the existing Accept header.
AWS API Gateway & URI Versioning
URI versioning on AWS can be achieved in a more simple way, in comparison to the header versioning solution, mentioned above. This might seem a bit tricky to set up at first, but honestly, this is a pretty simple and awesome way to version your API while making your life less complicated in terms of code management and complexity.
For implementation check this article
https://wojtek.cloud/api-versioning-on-aws-api-gateway/
Summary
API versioning is the practice of transparently managing changes to your API. For most APIs, versioning in the URI path is the most straightforward solution. Updating an API is necessary, but also risky without proper versioning, things break. And when things break, consumers lose trust and look for a more stable alternative.
Conclusion
I hope you have learned something new today. Share this with your friends & give a thumbs up for more content like this.