Structuring the Web API Versioning Stack

Question

So I spent the last few hours wading through all the genuinely useful tips for the Web API Versioning. Some of my favorites, for those who have as much fun as I do, in a certain order:

API versioning guidelines?

ASP.NET MVC REST API Versions

http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html

http://www.pluralsight.com/courses/web-api-design

http://www.pluralsight.com/courses/implementing-restful-aspdotnet-web-api

So, all of these tips were very helpful in developing what is essentially the API "interface". We can reprogram API calls ... Now I am in the difficult part.

This is a data-rich application for a multi-product company (this is new) that makes monthly releases. Some large customers who need long-term support for API calls, some smaller customers who need the latest releases. We could deal with something similar to releasing APIs with milestone / long-term support. Excellent.

But in practice it will be very dirty, very fast. We worked hard to separate the layers of our own website, the beta internal / external APIs, the repository layers, and even the download SDK. We separate each issue into separate branches, but SAAS - we host the database. Thus, we will not only be able to display API calls, but all this underneath. Business logic, repository and database. Even if Unit / Integration testing does not begin.

Thus, an attempt and probably a refusal only to ask one question here.

Is there a decent template for structuring a multi-level, data-driven .NET application for working with multiple versions?

In particular, how the database will change and how you can structure the overall stack up to version. Some ideas that I have include:

• Updating and Deploying Legacy Stack Versioning Branches
• Saving all in one project, but using folders / namespacing all the way down
• Further separation of projects - therefore, in the API solution there are several "Controller" projects with similar concepts for logic / repo levels.

We have quite a few developers, and no matter how much I have written documentation on aces, in reality it will be read only when something does not work. Therefore, ideally, this should be as obvious as possible for developers to get this right.

Answer 1

There is no ideal solution that matches every situation, whether data driven or not.

It is really hard to answer. It is best to use several version control strategies.

For example, if a database change simply adds a new column, older versions of the API may ignore the new columns.

If changing the database means that you need to completely overwrite the repository layer, then you may need to create a new repository and a new controller instead of simply versioning the API. Then at the endpoint, you can either change the route, or consumers could call the replacement endpoint.

If significant changes occur at all API levels, version control in IIS with a separate virtual directory can be performed for your solution (and this can have corresponding branches or labels in the source control in order to support only errors / corrections).

The idea of ​​/ namespacing folders can be very confusing for developers, so I would leave it. Routing (ie [Route ("/ v4 / Orders")]) may be the best way to handle this. Again, it depends on how much code and the nature of the changes.