Home > Web API > Designing Web API Versioning

Designing Web API Versioning

In this post I am going to talk about some of the commonly used Web API versioning strategy and hope it will help you decide which one is best suitable for your scenario.You will also see that there is no right or wrong way of designing them but I am always about options and different approaches, ultimately it is you who have to decide which approach is best suitable for you.

Uri based approach:

In this type of versioning strategy the versioning is embedded in the URI and probably the most popular one.However I personally think it is quite anti-REST as with each version the URI changes. REST is very resource oriented and it means once you have defined the URI(address) to the resource then it shouldn’t change just because you have a new version of that resource. This also means that the physical URI surface area will increase in terms or URIs and the number of deployments.

Lets take a look at an example

GET http://api.constosco.com/v1/user
Host: api.constosco.com
Accept:application/json

As you can see when a new version v2 is released the URI for the user resource will change and lot of your clients will have to point the URI to http://api.contosco.com/v2/user. The clients will have to keep up with your latest version if they prefer to use your latest version all the time. There is no easy way to make the version optional and return the latest version but in terms of ease and implementation it is the best approach.

Query string based approach:

In this type of strategy the versioning is appended as a query string and it is quite popular too. The version is passed as a query string so the URI doesn’t change when the version is changed, however make sure you are very clear on how you will handle versioning when the versioning is not provided.

GET http://api.contosco.com/product/1234?v=2.0
Host: api.constosco.com
Accept:application/json

But consider this that the query string parameter is optional, so what would happen if somebody request it as http://api.contosco.com/product/1234. Do you return the oldest supported version or do you always return the latest version. There is no easy answer to this and depending on your requirement and how you foresee your Web API’s changing you might choose one over the other.

In my personal experience always return the latest version as this will allow your API consumers to either stick to the older version by specifying the version number or deal with the latest version if there are any breaking changes.

Content Negotiation based approach:

This is my favorite one and is getting slowly popular and in my opinion more REST than the above two.In this strategy the version is passed as content negotiation header. This way the version doesn’t appear nor in the URI or in the query string and the client doesn’t have to really change much to keep up with your latest version. However you still have to decide how do you handle the default versioning when no version is specified as part of content negotiation.

GET http://api.contosco.com/product/1234
Host: api.constosco.com
Content-Type:application/vnd.constosco.1.0

Where the "1.0" at the end specifies the version and the application/vnd specifies it is a vendor specific header. Another thing I have noticed is that some people because of ease pass the version in the "Accept" header even if it is an HTTP POST or PUT. I think if you are going down this path then make sure "Accept" is for GET and "Content-Type" is for POST or PUT.

GET http://api.contosco.com/product/1234
Host: api.constosco.com
Accept:application/json;version=1

 
And this is how the POST will look like.

POST http://api.contosco.com/product
Host: api.constosco.com
Content-Type:application/json;version=1

 

Custom Request Header based approach: Last but not the least is using a custom “x-*” header to specify the version and specifying a date as the version. This is something I noticed when I first started looking into your Azure Service Bus and how the QueueClient and TopicClient build the version header into their request. I guess this is a trend Microsoft have started and you can see it across the Azure Platform. I really like this approach and may be in my next project I’ll get a chance to implement it.

GET http://api.contosco.com/product
Host: api.constosco.com
x-ms-version:2015-05-25

 

Another aspect of the Web API versioning design is that, how many versions should you keep on supporting and like many software philosophies there is no definitive answer. In my experience maintaining and supporting multiple versions of Web API can be very complex,error prone, at times cruel and can prove very costly (both financially and mentally). So make sure you are designing it correctly and your upper management understand the complexity behind deployment, bug fixes, writing and fixing test etc while you are supporting so many versions. The general rule of thumb in my personal experience is to only support 2 versions of any given resource. Also make sure you have clear strategy of maintaining versions for related resources.

Deprecating older versions:

The simplest way to inform the clients that the version they requested for a resource is deprecated is by adding a “Deprecated” header with a value “true” to the response. Let say that the request from the client for a product with id 1234 is something like this.

GET http://api.contosco.com/product/1234?v=1.0
Host: api.constosco.com
Accept:application/json;version=1

 

Then the return response should be

 

HTTP/1.1 200 OK
Content-Type: application/json; version=1
Deprecated: true
{"id":"1234", "name":"Brown Rice", "trade-number":"99804169"}

 

I hope this post has given some insight into the Web API versioning and in the next post I’ll show some code to show how this all comes together.Happy versioning !!! 🙂

Advertisements
  1. September 19, 2016 at 9:55 am

    Reblogged this on ITelite.

  1. June 30, 2015 at 11:54 am
  2. September 8, 2015 at 5:58 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: