摘要: 到目前为止，已经负责 API 接近两年了，这两年中发现现有的 API 存在的问题越来越多，但很多 API 一旦发布后就不再能修改了，即时升级和维护是必须的。一旦 API 发生变化，就可能对相关的调用者带来巨大的代价，用户 …

 到目前为止，已经负责 API 接近两年了，这两年中发现现有的 API 存在的问题越来越多，但很多 API 一旦发布后就不再能修改了，即时升级和维护是必须的。一旦 API 发生变化，就可能对相关的调用者带来巨大的代价，用户需要排查所有调用的代码，需要调整所有与之相关的部分，这些工作对他们来说都是额外的。如果辛辛苦苦完成这些以后，还发现了相关的 bug，那对用户的打击就更大。如果 API 经常发生变化，用户就会失去对提供方失去信心，从而也会影响目前的业务。

但是我们为什么还要修改 API 呢？为了 API 看起来更加漂亮？为了提供更多功能？为了提供更好的性能？还是仅仅觉得到了改变了时候了？对于用户来说，他们更愿意使用一个稳定但是看起来不那么时髦的 API，这并不意味着我们不再改进 API 了。当糟糕的 API 带来的维护成本越来越大时，我想就是我们去重构它的时候。

如果可以回头重新再做一遍，那么我心目中的优秀的 API 应该是怎么样的？

判断一个 API 是否优秀，并不是简单地根据第一个版本给出判断的，而是要看随着时间的推移，该 API 是否还能存在，是否仍旧保持得不错。槽糕的 API 接口各种各样，但是好的 API 接口对于用户来说必须满足以下几个点：

而对于开发人员来说，要求又是不一样的：

如何做到以上几点，以下是一些总结：

 1、  面向用例设计

如果一个 API 被广泛使用了，那么就不可能了解所有使用该 API 的用户。如果设计者希望能够设计出被广泛使用的 API，那么必须站在用户的角度来理解如何设计 API 库，以及如何才能设计出这样的 API 库。

 2、  采用良好的设计思路

在设计过程中，如果能按照下面的方式来进行设计，会让这个 API 生命更长久

除此之外，下面还列出了一些具体的设计方法：

 3、  避免极端的意见

在设计 API 的时候，一定要避免任何极端的意见，尤其是以下几点：

 4、  有效的 API 评审

API 设计完成以后，需要经过周密的设计评审，评审的重点如下：

 5、  提高 API 的可测试性

API 需要是可测试的，测试不应依赖实现，测试充分的 API，尤其是经过了严格的“兼容性整合测试”的 API，更能保证在升级的过程中不出现兼容性问题。兼容性整合测试，是指一组测试用例集合，这组测试用例会站在使用者的立场上使用 API。在 API 升级以后，再检测这组测试用例是否能完全符合预期的通过测试，尽可能的发现兼容性问题。

 6、  保证 API 的向后兼容

对于每一个 API 的设计者来说，都渴望做到“向后兼容”，因为不管是现在的 API 用户，还是潜在的 API 用户，都只信任那些可兼容的 API。但向后兼容有多个层次上的意义，而且不同层次的向后兼容，也意味着不同的重要性和复杂度。

 7、  保持逐步改善

过去我们总希望能将现有的“不合理”的设计完全推翻，然后按照现在“美好”的思路，重新设计这个 API，但是在一段时间以后，又会碰到一样的状况，需要再推翻一次。 如果我们没有有效的逐步改善的办法，依靠推翻现有设计，重新设计 API 只能让我们回到起点，然后重现之前的过程。 要有一套行之有效的持续改善的办法来在 API 兼容的同时，改善 API 使之更好。

 8、  把握 API 的生命周期

每一个 API 都是有生命周期的，我们需要让 API 的生命周期更长，并且在 API 的生命周期结束时能让其平滑的消亡。

开发 API 的过程其实就是一个沟通交流的过程。沟通的双方就是 API 用户和 API 设计者。

 9、  一些具体的实施方案

在一个 API 不可避免要消亡或者改变的时候，我们应该接受并且面对这个事实，下面列举了几种保证兼容性的前提下，对 API 进行调整的办法：

来源:apkbus