c# - 构建用于版本控制的 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 的里程碑/长期支持版本的东西来管理。太好了。

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

所以，尝试和可能失败只在这里问一个问题。

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

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

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

我们有相当数量的开发人员，无论我写了多少 ace 文档，实际上只有在某些东西不起作用时才会阅读它。因此，理想情况下，开发人员需要尽可能明显地做到这一点。

Answer 1

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

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

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

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

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

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