所以我花了几个小时来浏览所有关于Web API Versioning的真正意义上的建议。我的一些最爱，对于那些和我一样有趣的人，没有特别的顺序：
Best practices for API versioning?
Versioning REST API of an ASP.NET MVC application
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
因此，所有这些建议都非常有助于设计基本上是＆＃34;前端＆＃34;的API。我们可以对API调用进行版本控制......现在，我正处理困难的部分。
这是一个大量数据驱动的应用程序，适用于拥有多个产品（这是一个新产品）的公司，每月发布一次。一些需要长期支持API调用的大客户，一些希望获得最新版本的小客户。我们可以使用类似于里程碑/长期支持版本的API来管理。大。
但在实践中，这将变得非常混乱，非常快。我们努力将我们自己的网站，beta内部/外部API，存储库层甚至SDK引导层分开。我们将每个版本分成不同的分支，但它是SAAS - 我们托管数据库。因此，我们不仅能够对API调用进行版本控制 - 而且还包括其下的所有内容。业务逻辑，存储库和数据库。我们甚至没有开始进行单元/集成测试。
所以，尝试并且可能失败只在这里提出一个问题。
是否有适当的模式来构建分层的，数据驱动的.NET应用程序以应对多个版本？
具体说明数据库将如何更改以及如何构建通用堆栈以对其进行全部版本化。我的一些想法包括：
我们有相当数量的开发人员，无论我写了多少ace文档，实际上它只会在某些东西不起作用时被阅读。因此，理想情况下，开发人员必须尽可能明显地做到这一点。
答案 0 :(得分：1)
没有适合各种情况的完美解决方案，无论是否为数据驱动。
这真的很难回答。您最好的选择是使用多种版本控制策略。
例如，如果数据库更改只是添加新列，则旧版本的API可以忽略新列。
如果数据库更改意味着您必须完全重写存储库层，那么您可能需要创建新的存储库和新控制器，而不是仅仅对API方法进行版本控制。然后在端点上，您可以对路由进行版本设置，或者消费者可以调用替换端点。
如果API的所有级别都发生了显着变化，那么在IIS上使用单独的虚拟目录进行版本控制可能是您的解决方案（并且这可能在源代码管理中具有相应的分支或标签，目的是仅支持错误/修复）
文件夹/命名空间的想法可能会让开发人员感到非常困惑，所以我会避开它。路由（即[路由（＆＃34; / v4 / Orders＆＃34;）]）可能是处理它的更好方法。同样，这取决于代码的数量和变化的性质。