Question

我们正在使用aspnet-api-version作为我们API的版本。虽然库允许在一个控制器上interleaving multiple version implementation。

[ApiVersion( "2.0" )]
[ApiVersion( "3.0" )]
[RoutePrefix( "api/helloworld" )]
public class HelloWorld2Controller : ApiController
{
    [Route]
    public string Get() => "Hello world v2.0!";

    [Route, MapToApiVersion( "3.0" )]
    public string GetV3() => "Hello world v3.0!";
}

我们希望将版本特定的控制器分开。

我看到版本特定控制器和使用此库的问题是我们必须重新实现所有API方法，无论它们是否已更改。考虑这个例子

[RoutePrefix("api/v{version:apiVersion}/values")]
[ApiVersion( "1.0" )]
public class ValuesController : ApiController
{
    // GET api/values
    [Route]
    public IEnumerable<string> Get()
    {
        return new string[] { "value1", "value2" };
    }

    // GET api/values/5
    [Route("{id:int}")]
    [Route, MapToApiVersion( "1.0" )]
    public string Get(int id)
    {
        return id.ToString();
    }
}


[RoutePrefix("api/v{version:apiVersion}/values")]
[ApiVersion( "2.0" )]
public class ValuesControllerV2 : ValuesController
{
    // GET api/values/5
    [Route("{id:int}")]
    [Route, MapToApiVersion( "2.0" )]
    public string Get(int id)
    {
        return id.ToString();
    }
}

V1 api（使用ValuesController）定义了两个API函数Get和Get(ById)。但是在覆盖ValuesControllerV2时v2 api Get(ById)，它必须重新实现或调用Get的基本方法，以使V2上的Get API可用。

是否有更好的策略，我们不必为API升级中保持相同的所有功能重新实现或写入传递。

Answer 1

首先，我建议您评估您的版本控制政策。大多数服务作者（和/或公司）定义了像 N-2 这样的策略。这将有助于您确定此问题的大小，或者它是否甚至是一个问题。

你可以使用继承，但是有龙。在Web API中，您还需要执行其他操作才能使其正常工作。内置实现不支持继承的 RoutePrefixAttribute 或 RouteAttribute 。您还应该考虑到 uninherit 一个动作。如果你落后API，这会使策略变得非常混乱。并非所有版本控制方案都是向后兼容或前滚的。

我强烈建议您将业务逻辑保留在服务之外。常见的基类非操作方法或扩展方法可以帮助减少重复的代码。如果每个操作的实现很小并且您已经建立了版本控制策略，那么复制就不是问题了。

无论是方法还是两者的结合都应该提供足够的灵活性。

API版本控制并在版本更新时重用现有实现

1 个答案: