This project is read-only.

Global routePrefix for versioning

Topics: Web Api
Dec 13, 2011 at 8:22 PM

I'm trying to attain this type of Url for my services:

Then when the api is updated:

I'm also trying to build this functionality into a class that uses the WebActivator.PreApplicationStartMethod().  I plan on building a NuGet package for myself so I can easily add this standard configuration to all of my future applications so I don't have to manually work in the Global.asax file.

Where is the best way to place the routePrefix of "api/v1.0"?

I'm presently using this in the static class in my App_Start folder:


... and this doesn't seem like the best way of handling the problem:


I'm trying to encapsulate this as much as possible while maintaining best practices and flexibility.  Any thoughts are welcome.


Dec 14, 2011 at 12:53 PM

Just curious, is there any reason you prefer having a version designator in the URL vs. solving it with content (MIME) types?

This seems quite brittle for clients and you either end up breaking lots of clients or having to support a lot of different versions at once :)

Dec 14, 2011 at 4:27 PM

Here's an article on the topic / pros and cons:


Dec 14, 2011 at 7:33 PM

@SiggiG - the only reason is to allow consumers to know which version they are consuming, but I really to want a best practice on this.  If you have one, I would like to know what your solution is.  I haven't had to deal with versioning but I know that its crucial to think about ahead of time, so any help on this is appreciated.

Dec 14, 2011 at 8:00 PM
gblock wrote:

Here's an article on the topic / pros and cons:


I just read this article and it makes sense, although I don't know how to implement this.  Is there some explanation somewhere that shows how I would enable this on my service?  Thanks.

Dec 20, 2011 at 5:06 PM
Edited Dec 20, 2011 at 5:08 PM

I'm trying to work out a solution to this myself, as well as handle different content types per REST resource.  I see quite a few discussions here on this and related subjects, but so far I haven't seen a solution.  The following discussion problably got the closest to what I'm looking for:

I'll try to post here once I've found something, but my requirements are roughly:

1) Select the correct API method based on request Accept header + attribute data on the method.
 - 1a) First try to find an exact match complete with version specifier
 - 1b) If content type doesn't have a version part, return the latest version.
 - 1c) Also return latest version if Accept header is not provided or is: (empty), */*, application/json.
2) If Accept header on request is not one of the above or maps to a resource in the system, return HTTP 415 (Media Type Not Supported)
3) Support quality parameter in Accept header to select the best version based on client preferences.
4) Select correct serializer/formatter based on last part of Content-Type string (+json or +xml to start with).
5) Set the correct Content-Type header on response based on an attribute on the API method returning the data, something like: [ContentType("application/vnd.mycompany.myapp-v2+json")]

Dec 20, 2011 at 5:29 PM

Actually, after thinking this further.. I'm only going to support content types with the version in it.  If we allow clients to always get the latest version, it's very likely they will break once you release a new version.  A client should ideally be coded against a specific version of your resources.