Generally versioning in software industry has very vital part. We do assign a number or name to a particular state of a software and describe the features and fixes done till that release. Yeah sounds interesting, this is the way companies develop software and manage their progress and efforts which also helps them document that software for their own use as well as the end users. Above is an overview about versioning but in this post I will explain about how to create versions for your Asp.net Web API application and will verify the versioning using postman ( on how to use postman you can look to my post http://techintalk.com/post/2017/06/14/postman-test-automation-part-1 ).
As per importance perspective, I have divided this tutorial into two half's. This is the first one where I have explained what, why and how parts. In second part we will try to implement version in asp.net web api project you can find code on github.
Part-1 : http://techintalk.com/post/2017/08/05/asp-net-webapi-versioning-part-1
Part-2 : http://techintalk.com/post/2017/08/06/asp-net-webapi-versioning-part-2
Lets start with why part, recently I came across a requirement to publish new changes to live ( production ) webapi without effecting existing customers. Our existing api is been used by thousands of existing users from android and iPhone apps. Instead of overriding we were required to expose new changes to \v2 which meas our new release will be used thorough different end point. The best thing about programming is that you can achieve same goal through different ways, so same was the case here. My initial research bring me many possible ways to achieve this. Like SCOTT's solution and Infoworld's solution and some more online implementations. Overall there were two main solutions, one was to use Annotations with third party libraries and access API's through versioned urls i.e. www.example.com/webapi/v1, www.example.com/webapi/v2 and so on. Look at the image below :
Other solution ( more appropriate to me ) was sending api version info in separate header without changing the url scheme. Look at the image below :
I liked that because for this we were not required to change much in webapi end. We just need to add another layer in HttpRequest cycle and before request reach to the controller we could easily process its headers and find the version header value and forward the request to that particular controller, sounds crazy yeah it is. Another reason was that in any case either url scheme change or add header we were required to change mobile app implementation anyway.
I hope till now it make sense that why and in which scenario we need versioning and what are best possible ways to achieve this. In next part we will create a sample asp.net webapi project and implement api versioning in that and will also test that through postman.