6

每当我听到关于发布第 1 版 API 的讨论时，总是伴随着这个普遍的想法：

我们还不能发布我们的 API，因为我们必须在第一时间把它做好。

这是Vic Gundotra最近的一个例子，但还有很多其他的例子，包括 Stackoverflow 本身，早在 API 发布前一天。

我不明白的是，为什么第一个版本必须如此“正确”？使用 API，您可以实现版本控制和良好的文档，如果您做得很好，这并不难，为什么对版本 1 API 如此珍贵？

从一个版本到另一个版本，因为它是版本化的，所以 API 可以在没有任何重大更改的情况下发生巨大变化，因为旧版本仍然受支持。我想知道为什么关于发布 API 的大问题..？

4

3 回答 3

8

从一个版本到另一个版本，因为它是版本化的，所以 API 可以在没有任何重大更改的情况下发生巨大变化，因为旧版本仍然受支持。

这意味着两件事：

  • 维护一个 API 的多个版本。即使您只支持“最后 3 个版本”，这仍然是一个负担。特别是，如果您公开了稍后要删除的功能，则意味着您无法进行任何清理工作，这些清理工作将作为删除的一部分提供，直到 N 个更多版本出现和消失。考虑由于 API 的重大变化而可能对存储数据产生的任何影响——当它们被多个系统使用时迁移存储表示，并根据不同的发布计划进行更新，这真的很痛苦。（是的，实现和 API 之间是有区别的——但 API 的变化通常最终意味着整个堆栈的变化。）
  • 最终激怒了很多开发者。即使你给出了很多警告，如果他们不得不进行重大的重写，人们也会感到恼火，因为 1.0 版是垃圾，当 1.4 版发布时，1.0 版将被删除。

正确设计 API 是一项棘手的工作。是的，在实用主义和完美主义之间需要取得平衡——但这并不像你想象的那么简单。

我还要指出，（比如说）一个有 10 个用户快速发布然后更改它的开源项目与像谷歌或微软这样为全球开发者社区这样做的公司之间存在相当大的维护差异。大公司的内部 API（你不能轻易修复整个代码库）和小公司的内部 API 之间甚至有很大的区别，你可以随时改变世界。

我对做出如此大的事情感到惊讶感到有些同情——但这表明你还没有经历过改变 API 可能意味着的痛苦。你可能同样感到惊讶——甚至更惊讶——一旦一个错误的决定浮出水面，做出根本性的改变是多么困难。

（免责声明：我为谷歌工作，但不在 G+ 领域。此答案中的观点是我自己的，不代表谷歌。）

于 2012-08-04T07:17:46.407 回答
2

我认为这有点难以回答。但是让我试试。你做你的编程，但你第一次做对了吗？

好吧，我的经验是，我从某种方法开始，并且确实在增长。测试为绿色后，我查看它，发现它不够好。我正在添加我试图“清理”它的其他方法。

现在，用于更大软件包的 API 根本不是那么“小”。而且我敢打赌，从一开始，您甚至都没有接近您认为“足够好”的东西。但是，如果您发布一个 API，您就必须使用它。你不会结交很多朋友破坏 APIS。因此，如果您对您的代码有些认真，您将支持不同的版本。

我建议看看 GTK 的历史。有 GTK 1.2.x 和 2 之后的东西。我们曾经根据 GTK 1.2 编写软件并且并不“高兴”，因为 2 与 1.2 不兼容。所以该软件仍然停留在 GTK 的 1.2.x 中......

所以不是通常的方法不是你仍然有一个旧的 API 在运行但它已经坏了。因此，程序员不太乐意很早就发布 API（恕我直言）

于 2012-08-04T07:08:29.933 回答
0

您可能会要求提供可扩展的 API，例如：

APIclass::anAPIcall(Xclass Xparam, Yclass Yparam, void *userData, void *extensions);

.. 'extensions' 在 V1.0 中作为 Null 传递。

您可以与供应商达成一致，即在以后的版本中将不支持 V1.0 提供的功能（但将继续提供）。

于 2012-08-04T07:22:46.100 回答