api - API 向后兼容性的最佳实践

Question

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

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

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

if (APIVersion == 1) {

} else if (APIVersion == 2) {

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

}...

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

谢谢，
标记

Answer 1

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

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

如果变化很大，你可以添加一个新的search2使用新接口(interface)的服务。然后你标记search不推荐使用的方法(但仍然有效且向后兼容)。通常当你这样做时，你可以重构 你的代码以这样的方式，几乎所有的逻辑都在 search2方法，以及您的旧 search方法调用 search2在内部使用修改后的参数(并适本地重新格式化结果)。如果您正确执行此操作，您将永远不需要更改 search方法了。当你改变你的表等时 - 你只需要修改 search2 .

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

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

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