为版本化构建Web API堆栈
为版本化构建Web API堆栈
我已花了几个小时阅读有关Web API版本控制的一些真正出色的建议。以下是我最喜欢的一些建议，按照没有特定顺序排列：\n- API版本控制的最佳实践？\n- 对ASP.NET MVC应用程序进行REST API版本控制\n- http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html\n- http://www.pluralsight.com/courses/web-api-design\n- http://www.pluralsight.com/courses/implementing-restful-aspdotnet-web-api\n所有这些建议对于设计实质上是API的“前端”非常有帮助。我们可以对API调用进行版本控制...现在，我要解决困难的部分了。\n这是一个数据驱动的应用程序，属于一个拥有多个产品的公司（这是一个新产品），每月发布。一些大客户希望长期支持API调用，一些较小的客户希望获得最新版本。我们可以通过类似里程碑/长期支持版本的API来管理这些需求，很好。\n但实际操作起来会变得非常混乱，非常快速。我们努力将自己的网站、内部/外部测试版API、存储库层甚至SDK分离开来。我们将每个发布版本分成单独的分支，但这是SAAS - 我们托管数据库。因此，我们不仅仅需要对API调用进行版本控制，还需要对其下面的所有内容进行版本控制，包括业务逻辑、存储库和数据库。更不用说单元测试/集成测试了。\n因此，我只有一个问题，尝试并可能失败。\n是否有一个合理的模式来构建一个分层、数据驱动的.NET应用程序以应对多个版本？\n具体来说，数据库将如何更改以及如何构建通用的堆栈来进行版本控制。我有一些想法，包括：\n- 更新堆栈的旧源代码分支并部署这些分支\n- 将所有内容保持在同一个项目中，但在整个过程中使用文件夹/命名空间\n- 进一步拆分项目 - 因此API解决方案具有多个“控制器”项目，逻辑/存储库层有类似的概念\n我们有相当数量的开发人员，无论我写了多少好文档，实际上只有在出现问题时才会被阅读。因此，理想情况下，开发人员需要尽可能明显地正确理解这一点。
问题的出现是因为在构建Web API堆栈时，版本控制是一个常见的挑战。由于不同的数据库变更和API更改可能会导致不同层级的变化，没有一种适用于所有情况的完美解决方案。
解决方法可以采用多种版本控制策略。例如，如果数据库变更仅仅是添加一个新列，旧版本的API可以忽略新列。如果数据库变更意味着必须完全重写存储库层，则可以创建一个新的存储库和新的控制器，而不仅仅是对API方法进行版本控制。然后，在端点上，可以通过版本化路由或者消费者调用替代端点来处理。
如果API的各个层级都发生了重大变化，那么在IIS上进行版本控制，使用单独的虚拟目录可能是解决方案（这可能在源代码控制中对应有相应的分支或标签，以支持仅限于错误修复的情况）。
关于版本控制的文件夹和命名空间的想法可能会让开发人员感到非常困惑，因此我建议远离这种方法。处理版本控制的更好方式可能是使用路由（例如[Route("/v4/Orders")]）。当然，这取决于代码量和变更的性质。