“公共API是永远的：只有一次机会可以解决问题”？

在一本OS书中，我刚刚读到“公共API永远存在：只有一次实现它的机会”。是真的吗 它仅适用于操作系统的API还是其他API？例如，对于Tasker，Locale和Pushover等Android应用程序的API，这是否正确？

通常，对于任何公共API都是如此，是的。一旦向公众公开了API，并且人们开始构建依赖于该API的应用程序，更改该API将变得极为困难，因为这样做会破坏所有这些应用程序。这往往既是技术难题，又是政治难题。

当然，可以更改公共API。确实发生了这样的情况，例如，项目将在一个发行版中贬低某个API，引入一个新的API，然后在将来的某个发行版中删除旧的API。但这假设在删除旧API之前，将使用旧API的每个（重要）应用程序都重写为使用新API。这通常需要数年时间。这意味着公共API的所有者对使用该API的其他所有项目都施加了成本。由于通常有更多的API使用者，因此这些使用者往往是一个相对强大的政治游说者。

引用作者是Joshua Bloch，声明来自他的Bumper-Sticker API设计文章：

像钻石一样的公共API永远存在。您有机会把它弄对，所以尽力而为。

有关这方面的更多详细信息，作者请读者参阅他在会议上的演讲“如何设计好的API及其重要性”。幻灯片为什么API设计对您很重要，您可以很清楚地表明这与任何编程活动（操作系统无关，对作者无关）都是如此：

• 如果您进行编程，则说明您是API设计人员

  • 好的代码是模块化的-每个模块都有一个API

• 有用的模块往往会被重用

  • 一旦有用户模块，就无法随意更改API
  • 好的可重用模块是公司资产

• 通过API进行思考可以提高代码质量

幻灯片结论也强调了此作为一般方法：

• API设计是一项高尚而有益的工作

  • 提高了许多程序员，最终用户，公司...

API总是在变化，否则系统升级的重点是什么？仅更换内部零件？

系统的每个版本都会带来新的API，旧的API变得过时，过时的API消失。

API的更改在技术和通信方面都必须非常小心。

我的观点是，一旦发布，API的“版本”将永远存在，但是您可以通过发布“ 2.0” API来弃用它（有几种示例正在发生这种情况-目前，我可以想到Strava谁发布了一个2.0版的API，用于开发以消耗其服务）。

问题是无限地支持原始API广告...我想这取决于旧API的用法以及这些API使用者对您的价值。

回到Windows 3.x和9x等的“旧时代”，一旦发布，就完成并设置了这些OS API。现在，操作系统更新一直被推送，因此可以发布新的API，但是我认为，只要您运行的是特定的OS风格（主要版本），这些API只会添加，而不会删除...可能不会不过，“下一个”主要版本就是这种情况。

嗯，也许我偏离了最初的问题意图。

这取决于它是哪种类型的API（我假设是要进行重大更改，否则该声明显然是不正确的）。

如果调用者可以选择他们正在使用的版本（例如，与调用应用程序捆绑在一起的库/框架），则更改API并不是一个大问题-但这对软件的声誉仍然不利。人们喜欢无缝升级。

另一方面，当人们不能继续使用旧版本的API（例如，通过在线服务，或者浏览器或操作系统等无法很好地运行旧版本的东西）时，以不兼容的方式更改API是非常糟糕的确实，因为它将破坏所有使用它的软件，并且不会同时更新。这会给开发人员带来维护成本，并且他们会讨厌您。而且，未维护和中断的软件也会对您造成严重影响。

另一方面，至少有一个API提供者不断引入API的重大变化并取得了可笑的成功：Facebook。但是他们确实非常小心地管理更改：有一项已发布的政策，至少在90天之前宣布并解释了重大更改，开发人员可以选择在该时间段内尽早激活它们。

如果您有远见，请在API本身中包含版本号。无论是在连接/初始化调用上，还是在每次调用参数列表开头附近的某个位置，API都可以随着时间的发展而变化，而不会破坏现有的客户端。

尽管我们所做的只是尽力而为，但是随着时间的变化和改进的来临，有时我们需要更新信息，就像许多大型供应商所做的一样（例如面书多次更新，twitter一次重大更新）。转向oAuth和一些主要的功能，但最多可能都进行了改进，因此没有频繁的更改。是的，请不要停止支持较早的版本，这很痛苦！:)

每当您发布任何种类的通信协议（显然包括一个API）时，就可以正确地实现该协议/接口必须向后兼容且可扩展的意义。

这使您可以添加新功能并发布新版本，而不必担心会破坏使用旧版本的用户。在软件世界中，您永远不会遇到这样的情况，即您只能在某个时间点进行硬转换，并且每个人都放弃旧版本并开始使用新版本。