Question

我目前负责使用.Net和Web Api开发相当复杂的REST API。

接口应该由各种公共和私人（内部）客户端使用。我读了很多关于你应该如何对api进行编辑的内容，但是看法似乎非常不同。

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

现在我的问题是，负载均衡器受硬限制，只支持第4层负载均衡，因此我无法检查传入请求的URL /标头等，以将它们路由到正确的版本申请。

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

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

ver1.api.domain.com

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

Answer 1

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

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

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

        DoSomething();

        return Ok(result);
    }


}

在第一个版本发布之后，我们介绍了Get方法的第二个版本，我们可以做类似

的事情

<强>〔路线（ “汽车/ {ID} / V2”）]

public async Task<IHttpActionResult> GetCarsVersion2(int id)
{
    DoSomethingElse();

    return Ok(result);

}

所以现有客户仍然会参考旧的Uri / Cars / {id} ，而新客户可以使用新的Uri / Cars / {id} / v2。

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

带负载均衡器的Asp.Net Web Api版本控制（第4层）

1 个答案: