2

我们目前处于将部署到 Windows Azure 的新项目的开发阶段。该产品将是一个使用新的 ASP.NET MVC Web API 的可公开访问的 Web API。我们需要做的是随着时间的推移支持 API 的多个版本。例如，当我们部署它时，它将是版本 1。除非强制更改合约，否则此版本号不应更改。这意味着，如果在版本 1 中，我们有一些服务路线，例如：

/v1/user/{id}

它支持 GET/POST，对于 POST，它支持 Name 的值。好吧，也许在版本 2 中，我们想要更改 POST 接受的内容，现在我们将 Name 更改为 FullName，它还支持 FirstName 和 LastName。

这会产生任何使用版本 1 和该方法的人的问题，我们所做的新更改将破坏它们的功能。

所以我们希望能够在其中添加服务版本控制支持

/v1/user/{id}

将继续工作并访问旧库等。我们将版本 2 并排部署到它，以便消费者可以迁移到使用

/v2/user/{id}

而我们慢慢淡出旧的。

因此，简而言之，我们希望能够在 Windows Azure 中并排托管多个版本的 Web 服务，其中将包含不同的路由/合同、不同的核心库等。有人知道我们如何做到这一点吗？

4

2 回答 2

0

您可以使用 ARR 来提供路由功能。它是一个 IIS 模块，可以通过 Azure 启动任务添加。请参阅这篇关于如何安装 ARR 的帖子：

http://robindotnet.wordpress.com/2011/07/21/how-to-install-iis-application-request-routing-in-windows-azure/

然后，您将应用程序的每个版本作为单独的部署托管，并设置 ARR 以转发到正确的 *.cloudapp.net 地址。

另一个想法是在同一个部署中托管所有版本，并使用主机标头在它们之间进行路由。即（version1.yourdomain.com，version2.yourdomain.com）。

请参阅服务定义架构的 WebRole/Sites/Site/VirtualApplication 部分：

http://msdn.microsoft.com/en-us/library/windowsazure/gg557553.aspx

于 2012-04-26T14:30:52.257 回答
0

对 REST API 进行版本控制是一个棘手的问题。我认为没有一个正确的答案，但有很多讨论。大部分讨论都集中在 API 的设计上，例如 URI 和资源的布局，而不是它的技术实现。如果您还没有完全准备好将版本号放在 URL 中，我建议您先考虑一下，然后尝试弄清楚如何实现它。

SO上有几个起点：

于 2012-04-26T14:37:40.720 回答