Asp.Net Web Api版本控制与负载均衡器(第4层)

本文关键字：均衡器 4层 负载 Net Web Api 版本控制 Asp | 更新日期: 2023-09-27 18:00:25

我目前负责用开发一个相当复杂的RESTapi。Net和Web Api。

该接口稍后应该由各种公共和私人（内部）客户端使用。我读了很多关于你应该如何版本你的api的文章，但意见似乎很不一样。

该应用程序在多服务器环境中运行在负载均衡器后面。

现在我的问题是，负载均衡器受到严格限制，只支持第4层负载平衡，所以我无法检查传入请求的URL/标头等，以将它们路由到应用程序的正确版本。

我们不想在我们的代码库中有版本化的api控制器，因为我们有很多外部依赖项，这些依赖项应该经常更新，所以我们可能会破坏一些功能。

目前，它似乎是使用子域进行版本控制的唯一解决方案，例如

ver1.api.domain.com

有什么反对这种方法的吗？你有其他解决方案吗？

Asp.Net Web Api版本控制与负载均衡器(第4层)

版本控制方法的问题是，所有资源都会有重复的条目，包括未修改的条目。

在我看来，更好的方法是在Uri中包含资源的版本。让我们看一个具体的例子。假设有一个像下面这样的CarsController：

public class CarsController : ApiController
{
    [Route("cars/{id}")]
    public async Task<IHttpActionResult> Get(int id)
    {
        DoSomething();
        return Ok(result);
    }

}

在第一次发布之后，我们引入了Get方法的第二个版本，我们可以做一些类似的事情

[路线（"cars/{id}/v2"）]

public async Task<IHttpActionResult> GetCarsVersion2(int id)
{
    DoSomethingElse();
    return Ok(result);
}

因此，现有客户端仍然引用旧的Uri/Cars/｛id｝，而新客户端可以使用新的Uri/Cars/{id｝/v2。

此外，如果两个版本之间没有太多差异，则可以重构原始实现以满足新的需求。这反过来又减少了代码重复。

相关文章：