构建用于版本控制的 Web API 堆栈

Question

因此，在过去的几个小时里，我一直在浏览所有关于 Web API 版本控制的真正绝妙的建议。我最喜欢的一些，对于那些和我一样有趣的人，没有特别的顺序：

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

因此，所有这些建议对于设计本质上是 API 的“前端”非常有帮助。我们可以对 API 调用进行版本控制……现在，我开始着手最难的部分了。

这是一个大量数据驱动的应用程序，适用于拥有多个产品（这是一个新产品）每月发布的公司。一些需要长期支持 API 调用的大客户，一些需要最新版本的小客户。我们可以通过类似于 API 的里程碑/长期支持版本来管理这一点。太好了。

但在实践中，这会变得非常混乱，非常快。我们努力分离出我们自己网站的各个层、beta 内部/外部 API、存储库层，甚至是用于启动的 SDK。我们将每个版本分开到单独的分支中，但它是 SAAS - 我们托管数据库。因此，我们不仅能够对 API 调用进行版本控制，而且还能够对其下的所有内容进行版本控制。业务逻辑、存储库和数据库。我们甚至不开始单元/集成测试。

因此，尝试并可能失败在这里只问一个问题。

是否有合适的模式来构建分层的、数据驱动的 .NET 应用程序以应对多个版本？

特别是数据库将如何更改以及如何构建通用堆栈以对其进行版本控制。我的一些想法包括：

• 更新堆栈的旧源代码控制分支并部署这些分支
• 将所有内容保存在同一个项目中，但一直使用文件夹/命名空间
• 进一步拆分项目 - 因此 API 解决方案有许多“控制器”项目，逻辑/repo 层的概念相似

我们有相当多的开发人员，无论我编写了多少 ace 文档，实际上只有在出现问题时才会读取它。因此，理想情况下，开发人员需要尽可能明显地做到这一点。

Answer 1

没有适合所有情况的完美解决方案，无论是否由数据驱动。

这真的很难回答。最好的选择是使用多个版本控制策略。

例如，如果数据库更改只是添加新列，则旧版本的 API 可以忽略新列。

如果数据库更改意味着您必须完全重写存储库层，那么您可能需要创建一个新的存储库和新的控制器，而不仅仅是对 API 方法进行版本控制。然后在端点上，您可以对路由进行版本控制，或者消费者可以调用替换端点。

如果 API 的所有级别都发生了巨大的变化，那么在 IIS 上使用单独的虚拟目录进行版本控制可能是您的解决方案（这可能在源代码控制中具有相应的分支或标签，目的是仅支持错误/修复） .

文件夹/命名空间的想法可能会让开发人员非常困惑，所以我会避开它。路由（即 [Route("/v4/Orders")]）可能是更好的处理方式。同样，这取决于代码量和更改的性质。