我花了几个小时浏览了所有关于Web 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解决方案具有多个“控制器”项目,并针对逻辑/存储库层具有类似的概念