rest - 如何通过最新的服务器部署来支持多个移动应用程序版本？

Question

我正在尝试找出一个场景，但在网络上找不到任何相关信息。

假设我正在部署一个带有后端 (v1.0.0) 的 Android 应用程序 (v1.0.0)。 在某个时候，我会进行一些更改，并将应用程序更新到 v1.0.1，将后端更新到 v1.0.1，它们将完美运行。 但是我怎样才能支持以前版本的应用程序(也许新的服务器版本为一个特定请求提供另一种响应格式)？

我想过为每个版本的服务器进行单独的部署，但对于许多更新来说，这意味着会产生很大的资源影响。 另外，在我看来，强制用户更新似乎不是一个好的选择。

Answer 1

本质上，您可以采取多种方式来做到这一点。确实取决于您的要求，但通常现实是以下内容的混合体。

根据经验，请考虑保持兼容的数据模型。如果契约(Contract)无法履行或者您意识到需要进行重大更改，请引入新版本的 API。如果旧客户端不支持，则强制更新。您还可以就支持每个以前版本的时间达成一致，然后强制更新，这将使您的生活比维护数十个版本的 API 更轻松、更简单。

向后兼容的数据模型

1. 每次发布​​时您都必须向后思考:

   考虑每个发布周期的增量建模。这样你就可以保留东西。

2. 当您忘记它并且需要根据数据切换行为时:

   在我实习期间发生过。如果您忘记添加协议(protocol)版本，您只需根据数据解码它可能是哪个版本。从一开始，您就可以始终在数据上有一个版本字段。此外，您还可以添加一组兼容的解析器版本。

在数据中包含协议(protocol)版本:

{
    "data": [ arbitrary data model],
    "protocolVersion": "v1"
}

根据协议(protocol)版本，您可以决定服务器端如何处理数据。您不需要记住客户端版本，只需记住协议(protocol)的版本。因为您可能发布:1.0.0、1.0.1、1.1.0，而您只更改 1.2.0 中的协议(protocol)。

但我认为问题在于，随着数据随后发生变化，服务器端处理的行为也会发生变化。

版本化 API

1. 有时您会看到主要版本的不同路径:

   • /api/v1/query

   • /api/v2/query

在向后兼容性被破坏或经过全面重新考虑后使用。因此并不是每个版本都会有增量。

使用带有客户端版本的查询参数:

• /api/query?v=1.0
• /api/query?v=1.1

和上一篇类似，只是写法不同。虽然我觉得这不是你想走的路。

跟踪客户端版本和使用的服务版本

实际上，每个客户端版本始终会使用多个请求和多个版本的服务。这使得维护变得更加困难。

始终记录和跟踪。版本和发布管理非常重要。了解您构建的版本的 git 哈希值，很多时候它可能会让人感到困惑，并且您在发布后仅更改了一个参数作为快速修复，而第二天就不再兼容了。

在每个版本中将所有服务版本映射到客户端版本，了解您真正构建的提交并使用标记和发布管理。

在每次发布之前测试所有内容

对向后兼容性有明确的要求。也许您只支持两个旧版本，然后使用所有两个客户端进行测试，新客户端与即将发布的服务器。记录一切。当你满足释放标准时，就去吧。

摘要

现实是多种解决方案的混合体。对向后兼容性有明确的要求。因此您可以在每次发布之前进行测试。必要时，强制更新。跟踪版本，并记录每个客户端版本以及与其版本一起使用的所有服务。