15

我正在开发一个与 JSON API 通信的 iPhone/iPad/Android 应用程序。

该应用程序版本的第一个版本已完成，现在正在进行其他开发阶段。在其他阶段，应用程序需要与新版本的 API 集成，并允许用户访问其他功能，例如新屏幕或现有屏幕中的修改行为。但是，该应用程序确实需要使用 API 的早期版本。

解决此类要求的最佳做法是什么？我可以在整个代码中进行检查：

if (APIVersion == 1) {

} else if (APIVersion == 2) {

} else if (APIVersion == ....) {

}...

但我担心这种方法的可扩展性。想到了工厂方法，但我不确定这会让我走多远。

谢谢，马克

4

2 回答 2

25

发布新的 API 版本是一件非常罕见的事情。通常，您只需添加新的可选参数或新方法即可实现向后兼容。例如，如果你有一个名为的方法search，但现在你对它的工作方式不满意，你可以通过多种方式来处理它：

  • 如果更改很简单，您可以添加一个mode默认为的新参数mode1（因此它是向后兼容的）。如果用户向mode2您提供您自己提出的正确if条件来检测它。（另外，通常你可以想出一个比“mode”更好的名字。）

  • 如果更改很大，您可以添加search2使用新界面的新服务。然后将search方法标记为已弃用（但仍然有效且向后兼容）。通常当你这样做时，你可以重构你的代码，几乎所有的逻辑都在search2方法内部，并且你的旧search方法在search2内部使用修改后的参数调用（并适当地重新格式化结果）。如果您正确执行此操作，您将不再需要更改search方法。当您更改表格等时 - 您只需要修改search2.

我的观点是，避免发布N+1API 的 -st 版本。如此大的版本意味着你所有的方法都发生了重大变化，而不仅仅是一个。许多主要的 API 从未发布其 API 的第 2 版，它们仍然使用第 1 版，只是稍微修改了其中的一部分，如上例所示。

如果您绝对确定要发布API 的 -st 版本，请为您的所有N+1方法创建新的入口点。如果您有一个名为 的文件夹，请创建一个名为 的新文件夹。重构您的代码，以便它使用大部分. 如果您认为这太过分了，那么我认为您还不需要-st 版本的 API。servicesservices-v2servicesservices-v2N+1

顺便说一句，不要将集中式 API（如 Google Maps）与分布式 API（如 Android）混淆。Android 一直在发布新的 API 版本，因为有数十亿台 Android 服务器（每台 Android 设备就是一台），而且它们都不能简单地由 Google 远程升级。下一个版本的 Android 仍然向后兼容上一个版本，增加数字只是为了表示新功能。例如，您仍然可以在 Android 7.0 上运行为 Android 3.0 构建的应用程序（用户可能会收到一些额外的警告，但应用程序会运行）。Android 应用程序开发人员使用这些数字来描述他们的应用程序的“最低要求”。然而，集中式 API 通常会增加其版本号，以表明重大的向后不兼容更改。

于 2012-05-23T09:30:44.207 回答
2

我猜你已经分离了关注点。我的意思是，获取应用程序的数据只能通过模型​​完成（例如）。

所以你只需要改变模型。

我的建议是只有一个入口点：“路由器”文件。此文件检查所需的 API 版本，并加载正确的文件。这样，您可以为每个 API 获得不同的文件。“路由器”文件不会很大，每个新的 API 版本都有自己的文件，因此您不会混合所有内容。

例如，在“路由器”文件中：

function dispatch() {
    switch (APIVersion) {
    case 1:
        use('file.1.ext');
        break;
    case 2:
        use('file.2.ext');
        break;
    case 3:
        use('file.3.ext');
        break;
    }
}
于 2012-05-23T09:18:15.183 回答