In this post, I am going to discuss Web API versioning using custom Header. We are already discussed versioning using URI i.e. namespace based versioning.
How versioning through Header?
To perform versioning through HTTP Header, we set a Header in request to differentiate API resources and on the server we have to check the Header and execute the controller that is specified by Header value.
What Header is to be used?
Have a look on following Header
Accept header parameters define:
Media type (e.g. application/json)
Character encoding (e.g. charset=utf-8)
Other parameter: vesion=1
I am using this approach for this post.
First, create a new Web Application with Web API template and create two controllers.
Get the version number from MIME parameter
To select controller based on Header parameter, we have to create a custom controller selector class which derive from DefaultHttpControllerSelector.
In this class, we are modifying the default controller selector behaviour by overriding SelectController method. In this, we find the version number from Accept Header parameter and then concatenate It with V, because our version V2 Controller method end with V2.
One more configuration
We have to register our CustomControllerSelector to ASP .NET web API. So some modification in WebAPIConfig:
We are simply replacing the default controller selector with our custom controller selector.
Time to execute
Build and run the solution with following parameters
Request to version 1:
Response we are getting is
Request to version 2:
Response we are getting is
That’s work perfect!
Argument around the web for versioning approaches
One day I was looking for current practices used for version of REST API.on web, I find many argument for using versioning through URI or Header, and even combinations of these and different approaches. Some are here taken from stackoverflow only for information:
Semmantically using version number in header seems better. But its far much more practical using the
URL: less error prone, best debuged, readily seen by developers, easily modifiable in rest testing clients.
Yoav Shapira said:
We found it practical and useful to put the version in the URL. It makes it easy to tell what you’re using at a glance. We do alias /foo to /foo/(latest versions) for ease of use, shorter / cleaner URLs, etc,
Using a version number in the URL should not be considered a bad practice when the underlying
implementation changes. “When the interface to a service changes in a non-backwards-compatible way, in reality an entirely new service has been created…From the client’s perspective, a service is no more than an interface and some non-functional qualities…if the interface to a service changes in a non-backwards compatible way, it no longer represents an instance of the original service, but is rather a completely new service.”
I hope that you will have better understanding of API versioning through Header and handling the HTTP Header. I would like to hear valuable feedback or question from you. It encourage me to write more quality article.
Happy Coding, Versioning 🙂