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条件。（另外，通常你可以想到一个比“模式”更好的名字。）
如果更改很大，您可以添加使用新界面的新search2服务。然后将search方法标记为已弃用（但仍在工作且向后兼容）。通常，当您执行此操作时，您可以通过这种方式重构代码，几乎所有逻辑都在search2方法中，并且您的旧search方法调用{ {1}}在内部修改参数（并适当地重新格式化结果）。如果您正确执行此操作，则无需再更改search2方法。当您更改表格等时 - 您只需要修改search。

我的观点是，避免发布API的search2版本。如此大的发布意味着您的方法 ALL 的重大变化，而不仅仅是一个。许多主要的API从未发布过他们的API版本2，他们仍然使用版本1，只是略微修改它的一部分，如上例所示。

如果您完全确定关于发布API的N+1版本，请为您的方法的所有创建新的入口点。如果您有一个名为N+1的文件夹，请创建一个名为services的新文件夹。重构您的services-v2代码，使其使用services的大部分代码。如果您认为它有点过分，那么我认为您还不需要services-v2 - 您的API版本。

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

Answer 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;
    }
}

API向后兼容性的最佳实践

2 个答案: