维护 API Rest 的多个版本答案

【问题标题】：Maintain multiple versions of an API Rest维护 API Rest 的多个版本
【发布时间】：2015-09-01 12:32:57
【问题描述】：

我有一个用 Express 制作的 API Rest，供 iOS 客户端使用。有时我必须对某些端点进行更改（重大更改），我将发布 iOS 应用程序的新版本，但如果客户端正在运行应用程序并且我部署了新的后端版本，则可能并非所有用户都更新客户端事件。

如何维护后端的多个版本？
在代码中没有复杂规则的情况下，有什么好的方法可以做到这一点
如果我执行不同的多个基础实例并以正确的版本响应每个客户端，现在要处理数据库吗？

@MikeBrant 建议我如何缩小范围

我正在使用

节点
快递
Postgres

我没有使用像sailjs 或loopback 这样的框架

【问题讨论】：

这是一个过于宽泛的问题，无法在这里回答，因为提供版本化 API 端点的方法有很多种，并且这些方法的适用性可能会根据框架类型（如果任何）您正在使用。此外，在某些情况下，您可能希望设置完全不同的基础架构集来处理不同的 API 版本，具体取决于应用程序的需求和修订之间更改的性质。
@MikeBrant 你能给出一些建议如何缩小范围
真的没有一个很好的方法来缩小这个问题的范围。必须熟悉您的应用程序逻辑、数据存储、路由机制等，才能考虑如何最好地为您的用例提供 API 版本控制。

标签： javascript ios node.js rest architecture

【解决方案1】：

Mike 是正确的，很难说对于您的特定 API 的最佳解决方案可能是什么。但是，为了给您提供一个可能的解决方案，这里有一个非常简单的方法来维护不同的 API 版本。当然，这是基于很多假设，可能不是您 API 的最佳或最简洁的解决方案。

对于简单的 API，您可以通过在应用中定义一个常量来维护不同的版本。此常量将成为 API 端点根的路径。通常，这将与您的应用程序版本具有相同的名称，例如“myApp/v1-8-5/”，假设您的应用程序版本是 1.8.5。在服务器端，您将为包含完整 API 的每个版本的应用程序维护一个目录。您的应用程序的每个新版本，您都将更新常量并将新目录添加到您的端点。

这不是最优雅的解决方案，如前所述，它可能不是满足您需求的最佳解决方案，但它是一个解决方案....

【讨论】：

假设这个方案，数据库怎么处理？
如果你正在改变你的数据库结构，那么所有的赌注都没有了。如果结构没有改变并且您只是添加到它，那么您的 API 中的代码应该解决这些更改。此外，只想再次声明，这可能不是您的 API 的最佳解决方案，需要更多详细信息才能为您的 API 提供具体答案。

【解决方案2】：

首先，REST 用于消耗资源，并且可以争辩说您使用它精确地将其与后端实现分离（这意味着它不关心您使用哪个数据库、框架……）。

其次，如果你真的对第一个版本有完整的实现，那么它应该被冻结，这意味着不要触及后端实现对于该版本，复制路线并相应地更改它们。

恕我直言（我会做什么）：

为第一个版本编写测试，以免破坏某些东西（强制）
为您的网址添加 REST 版本的前缀（与其他所有人一样，这里没有新内容），例如：api/v1/... 或类似的东西
由于您使用的是 express，您始终可以在路由前加上一些变量，比如说 apiPath（首先是 'api/v1'，'api/v2'），所以您最终会得到类似 app.delete(apiPath + '/photos/:id')

现在这是开始变得棘手的地方，这就是您的问题所在。如果它只是模型域（可以保存/检索的新数据），那么这很容易。使用属性的 getter/setter 补充模型 API 版本。假设您使用月光： `

userSchema.virtual('v1_properties').get(function() {
    return ['email', 'name'];
});
userSchema.virtual('v2_properties').get(function() {
    return ['email', 'name', 'surname'];
});
modelSchema.virtual('attributes').get(function() {
    // atributes that are prefixed with api version
    var self = this;
    var json = {};
    self[apiVersion + '_properties'].foreach(function(key) {
        json[key] = self[key];
    });

    return json;
});

` 对于二传手，你做同样的事情。当然结对是个坏主意带有模型的 API 版本，这仅用于示例目的。

很遗憾，如果您更改了特定的业务逻辑，这并不能解决问题。请记住，弃用是有原因的。如果您的更改确实破坏了旧 API 中的某些内容，那么我认为那里只有 2 个选项，即弃用第一个 API 或迁移数据时用户最终会更新他们的应用程序。如果他们对同一帐户使用不同的应用程序版本，这仍然意味着对他们来说，旧的 API 实际上已被弃用。

我希望这对您有所帮助。让我知道你是否有更多问题，或者您是否可以更详细地说明您的问题，我会尝试更新答案。 `

【讨论】：