API应该有版本号吗？

Question

我正在构建一个API,我打算随着时间的推移升级.在API中包含版本号作为参数是否合理？

我正在Ruby,Java,Erlang和C#中编写一个键/值存储API.我想构建一些可扩展的东西,因为我知道有很多我还没有想到的东西,可能必须在未来加入.但是,我想知道是否有一种干净的方式来执行此操作以及版本号是否也参与其中.

Answer 1

你可以做到,如果你只是让你的API向后兼容,那就更好了(恕我直言).它通常更容易,因为您不需要根据版本号分支,只需重新实现给定的方法.

我认为它确实非常特定于实现(以及特定于环境).我会做任何看似最简单/更好的事情.

我会说只要你以某种方式保持向后兼容性,那就好了.

Answer 2

如果您正在构建面向对象的API并且将版本号提供给工厂,那么这可能是合理的.它在动态数据中心API中也很常见 - 您向库询问数据,并且必须指出您希望数据返回的格式/版本.

更常见的是"传统"库(如在C/C++/.NET应用程序中链接到的那些库)完成的是:

• 提供API以获取库的版本号.这允许应用程序决定是否需要更新/更旧版本的库.

• 尽可能向后兼容.

• 添加功能,不要更改它们.如果你必须添加参数/输入或改变行为 - 创建一个新的函数,并保持旧的功能.

• 当你最终必须打破向后兼容性并且为了向后兼容而摆脱所有旧的残存时,有一个理智的版本方案,清楚地表明不兼容的版本.

Answer 3

我使用了几种支持某种版本控制的API,最着名的是ODBC.这些都不允许在API调用级别进行版本控制 - 它们都要求您在一次性基础上告诉库您要使用哪个版本 - 例如:

MyAPI::UseVesion( 2, 1 );

就个人而言,如果可能的话,我会避免这种路径(使你的新API向后兼容),并确保在单个呼叫级别进行版本控制是不可容忍的,也是不可行的.想象代码如:

MyAPI::Handle h = MyAPI::GeHandle( 2, 1 );    // get 2.1 version of handle
MyAPI::UseHandle( 3, 0, h );                   // use it somehow with a 3.0 function

您无法在编译时检测到不匹配,并且在运行时可能会或可能不会.Yechh!