2

We are currently in the development phase of a new project that will be deployed to Windows Azure. The product will be a publicly accessible web API using the new ASP.NET MVC Web API. What we are going to need to do is support multiple versions of the API over time. For instance when we deploy it will be version 1. This version number shouldn't change unless there is a forced contract change. Meaning, if in version 1, we have some service route such as:

/v1/user/{id}

And it supports GET/POST and for a POST, it supports a value for Name. Well, maybe in version 2, we want to change what the POST accepts and now we changed Name to FullName and it also supports FirstName and LastName.

This creates the issue of anyone using version 1 and that method, the new changes we make will break their functionality.

So we want the ability to add service versioning support in that

/v1/user/{id}

will continue to work and hit the old libraries, etc. And we deploy version 2 side by side to it so consumers can migrate to using

/v2/user/{id}

while we slowly fade out the old.

So, in a nutshell, we want to be able to host multiple versions of our web services side by side in Windows Azure which will consists of different routes/contracts, different core libraries, etc. Anyone know how we can do this?

jaryd
  • 861
  • 12
  • 21

2 Answers2

0

You could use ARR to provide the routing capability. It's an IIS module that you can add with an Azure startup task. See this post on how to install ARR:

http://robindotnet.wordpress.com/2011/07/21/how-to-install-iis-application-request-routing-in-windows-azure/

You would then host each version of your application as a separate deployment, and setup ARR to forward to the correct *.cloudapp.net address.

Another idea is to host all versions on the same deployment, and use host headers to route between them. i.e. (version1.yourdomain.com, version2.yourdomain.com).

See the WebRole/Sites/Site/VirtualApplication part of the service definition schema:

http://msdn.microsoft.com/en-us/library/windowsazure/gg557553.aspx

Richard Astbury
  • 2,323
  • 18
  • 28
0

Versioning a REST API is a tricky question. I don't think there is a single correct answer, but there is a lot of discussion. Much of the discussion is focused on the design of the API, such as how the URIs and resources are laid out, rather than the technical implementation of it. If you're not completely set on putting the version number in the URL, I would suggest thinking about that first, then trying to figure out how to implement it.

There are a few starting points here on SO:

Community
  • 1
  • 1
Brian Reischl
  • 7,216
  • 2
  • 35
  • 46