API向后兼容性的最佳实践

我正在研究与JSON API通信的iPhone/iPad/Android应用程序。API向后兼容性的最佳实践

该应用程序版本的第一个版本已完成，现在正在进行其他开发阶段。在其他阶段，应用程序需要与API的新版本集成，并允许用户访问其他功能，例如新屏幕或在现有屏幕中修改的行为。然而，该应用程序需要与之前版本的API相反。

解决此类需求的最佳做法是什么？我的可在全代码做的检查：

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

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

}...

但我很担心这种方法的可扩展性。工厂的方法让人想起，但我不知道这会让我感觉有多远。

谢谢，马克

来源

2012-05-23 Mark

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

如果变化是简单的，你可以添加一个新的mode参数，默认为mode1（所以它是向后兼容的）。如果用户提供mode2，则可以使用正确的if条件检测它，正如您自己提出的那样。（另外，通常你可以想到比“模式”更好的名字）。
如果变化很大，你可以添加一个新的使用新接口的search2服务。然后，您将search方法标记为已弃用（但仍可正常工作并向后兼容）。通常当你这样做时，你可以用这样的方式重构你的代码，几乎所有的逻辑都在search2方法中，而你的旧search方法在内部调用search2修改过的参数（并且适当地重新格式化结果）。如果你正确地做到这一点，你将不再需要改变search方法。当你改变你的桌子等 - 你只需要修改search2。

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

如果绝对的把握约释放你的API N+1 -st版本，ALL的你的方法创建新的切入点。如果您有一个名为services的文件夹，请创建一个名为services-v2的新文件夹。重构您的services代码，以便它使用最多services-v2。如果您认为它过度杀毒，那么我认为您不需要N+1-API版本。

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

来源

2012-05-23 09:30:44 wrygiel

谢谢。我采用了第一项重点建议。这些变化相当小，所以我设法执行API版本条件检查，并且扩展具有不同可选参数的方法，或者在某些情况下为每个API版本创建新方法。 API版本超出了我的控制范围，因为它是客户端API。 – Mark

这是一个非常好的答案，我希望我也能得到一些链接和指针。 – Alex

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

所以你只需要改变模型。

我的建议是，只有一个入口点：“路由器”文件。该文件检查所需的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-23 09:18:15

API向后兼容性的最佳实践

回答

相关问题