Question

我正在使用需要版本控制的API。现在，我正在这样做：

namespace MixApi.UI.Controllers
{
    [ApiVersion("1.0")]
    public class VoController : ApiController
    {
        [Route("api/v{version:apiVersion}/vo/order/")]
        public IHttpActionResult Method1() { }
    }
}

namespace MixApi.UI.Controllers.v2
{
    [ApiVersion("2.0")]
    public class VoController : ApiController
    {
        [Route("api/v{version:apiVersion}/vo/order/")]
        public IHttpActionResult Method1() { } // Improved this with new logic

        [Route("api/v{version:apiVersion}/vo/order2/")]
        public IHttpActionResult Method2() { } // New method for v2
    }
}

但是，假设我要添加一个新的控制器，例如ArticleController。我应该如何版本？应该是v1还是v2？

我认为它应该是v1，因为它是该控制器/端点的第一个版本。但是后来我意识到我正在对控制器（端点）进行版本控制，而不是对API本身进行版本控制。因此，对于这种情况下的版本控制，我有些困惑。

你们是怎么做到的？

Answer 1

您可以为一个控制器分配多个版本，在您的情况下，我可以考虑这样做，因此，如果您使用的是版本2，并且配备了全新的控制器，则可以为其分配一个或两个版本。

.card-header h3 {
  cursor: pointer;
}

我确实认为应该将版本视为完整产品，因此用户将使用版本2，因为它是最新版本（例如），但是突然之间，他们仅出于新功能就必须引用版本1。可能会造成混乱，而且似乎对客户不友好

Answer 2

最好在项目级别进行版本控制。您可以遵循许多版本控制指南。我想在https://semver.org/

处插入对语义版本控制准则的引用

这确保了从属应用程序的稳定性。

但是。假设我要添加一个新的控制器，例如ArticleController。我应该如何版本？应该是v1还是v2？

您应该发布应用程序的第一个稳定版本。然后，遵循版本控制过程。因此，第一稳定版将为v1.0.0，而类似添加控制器的修订版将被发布为v1.0.1。模块或应用部分的重大更改（例如代码优化，实施新技术等）应发布为v1.1.x

你们是怎么做到的？

在我的组织，我们每年都会增加主版本号。例如，在2018年v2.0.x，2019年v3.0.x中，依此类推。对于主要模块级别的发行版，我们将其从v2.0.1增加到v2.1.1。如果仅添加了一个控制器，我们会将其从v2.1.1更改为v2.1.2。您还可以参考开放源代码项目的发布页面以供参考（例如：https://wiki.ubuntu.com/Releases）

我想知道添加新的控制器/端点时如何进行版本控制。

假设您有一个主要版本v2.x.y，并且您的API端点是/api/v2/。如果现在添加/删除/修改控制器，您将使用v2.x.y+1新建一个版本。在这种情况下，您的API端点将保持不变：/api/v2/

除非它从v2.x.y+1变为v3.p.q，否则您的API端点应保持不变，位于/api/v2/。请注意版本号中的更改。

API端点版本化

2 个答案: