构建用于版本控制的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来管理.大.

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

因此,尝试并且可能失败只在这里提出一个问题.

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

具体来说,数据库将如何更改以及如何构建通用堆栈以对其进行全部版本化.我的一些想法包括:

• 更新堆栈的旧源控制分支并部署这些分支
• 将所有内容保存在同一个项目中,但始终使用文件夹/命名空间
• 进一步拆分项目 - 所以API解决方案有许多"Controller"项目,逻辑/ repo层的概念类似

我们有相当数量的开发人员,无论我写了多少ace文档,实际上它只会在某些东西不起作用时被读取.因此,理想情况下,开发人员必须尽可能明显地明白这一点.

Answer 1

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

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

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

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

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

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