为版本控制构建Web API堆栈

Question

我花了几个小时浏览了所有关于Web API版本控制的好建议。以下是我的一些最爱，供那些和我一样享受乐趣的人参考：

API版本控制的最佳实践？

在ASP.NET MVC应用程序中对REST API进行版本控制

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解决方案具有多个“控制器”项目，并针对逻辑/存储库层具有类似的概念

我们有很多开发人员，无论我写了多少文档，实际上只有在某些东西不起作用时才会阅读。因此，理想情况下，开发人员需要尽可能明显地正确使用这些内容。

- Paul Coghill

Answer 1

没有一种完美的解决方案适用于每个情况，无论是否基于数据驱动。

这个问题真的很难回答。最好的方法是使用多个版本控制策略。

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

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

如果在API的所有级别都有重大更改，则在IIS上进行版本控制，并使用单独的虚拟目录可能是您的解决方案（这可能具有相应的分支或标签，以支持仅限于错误修复）。

文件夹/命名空间的想法对开发人员来说可能会变得非常混乱，因此我建议避免使用它。路由（即[Route("/v4/Orders")])可能是更好的处理方式。再次，这取决于代码量和更改的性质。

- Karen B