导读：现今API在软件开发领域中扮演的角色越来越重要。计算和开发领域的进化在被不断升级的抽象计算和高级语言主导，但除此以外，也被开发平台、库、和架构的发展所推动。Douglass C. Smith 教授在 2006 年 IEEE 的报告中指出：后者的进程和发展将超越具体算法语言的发展。实际上是，开发人员也应该注意到这一点了：开发过程中的阻碍从学习算法和数据结构转换到了选择，学习和使用层出不穷的API上。但是很多程序员没有意识到API的优劣所导致的区别，以及为此需要设计好的API所要付出的努力。
微软在API设计上是很费心血的，这种努力和专注始于上世纪80年代Windows的诞生。他们理解一个平台的成功取决于这个平台所能吸引和拥有的开发者（Steve Ballmer的视频 ”developers,developers,developers” )。 .Net 的首席架构师 Krzysztof Cwalina 出了一本专门《.NET设计规范:约定、惯用法与模式》 指导开发人员。相似的，Sun（Oracle）也有相关的Java SDK的书籍。在一次采访中，Sun的前任首席架构师，Joshua Bloch(现任职Google)洋洋洒洒地总结了19页Sun在API设计上的理念。同样的，SAP雇佣了Carnegie Mellon大学的研究人员具体研发新的网络服务接口(web services interfaces)。这些业内大佬们的实例无不给了我们一个信号，API设计在推动软件使用和程序开发中的价值。
译者注：本文通过学术统计报告理论上证实API质量的重要性，循序渐进地例证：API的优劣如何评判，API的改进能多大程度地提高编程效率，以及为什么我们需要一个对开发人员友好（Developer-Friendly）的API。然后概括例举了优质API的特性，以及如何在实际操作中实现这些特性。
我们的主张
如果说书籍是以封皮判断，那么软件平台、服务、架构和库是由它们的API定义的。当开发人员评价一个API的时候，他们实际上是对API所有的服务和方案（package）进行评价。API设计是很聪明的投资，你得到的回报是忠实的开发人员。
研发人员和机构越来越意识到API质量的好坏直接影响到自己代码的质量。虽然将他人代码质量的好坏视为API作者的责任有些奇怪，但API质量影响到使用API代码质量的例子却越来越多。尽管使用复制黏贴，样板等类似的编程方法被视为是缺乏编程技能，但是即便是最出色的程序员（在使用API的时候）也无法避免使用这样的编程方式除非自己用代码重新包装API。不难看出每个研发人员用代码包装API都是在填补API天生的不足之处。因为API一旦出炉将被反复使用，所以越来越多的研发人员希望API的作者能填补API的天生不足。在有众多的开放式网络服务和免费开源组件可以选择的时代，研发人员默默的使用有天生不足API的日子已经一去不复返了。
为使API更加易学，易用，易除错作出的任何努力都可以直接提高使用API的程序员的效率。让我们回头看看开篇的主题：当今，研发人员将大量的时间花费在学习API，使用API和代码调试上，这些活动都是在通过包裹在多个复杂的API来实现一个业务逻辑。所以，更好的API会使研发人员有更高的效率。很多学术数据可以证实API的设计质量直接联系到编程的实际效率。2007的一份研究报道的数据表明API上哪怕是细微的变化，例如使用构造函数(constructor)取代工厂方法（factory methods）也可以大幅度地提高程序员的编程效率。他们的数据显示，使用constructor，不管程序员的经验、技术的区别，他们大多能在同样短的时间内完成；而使用factory methods，程序员们所需要的时间可以相差10倍。也就是说factory methods的API很打程度上取决于使用者。而取决于个人的工具不是一个好工具。相似的报道显示了编程效率可以相差10倍如果一个方法被放到不同的class里面。
很多时候在API软件不能很好地被使用的情况下，程序员会被指责太自我，或者恐惧新事物，不确定，疑惑（FUD）。但是实际情况是，API的质量不够好才是主导因素。常见的问题是API的文档不够清晰明了；API的方法太情景锁定（specific to scenario）；API 有太多Dependencies，与其使用它，还不如自己写来地快。我们可以得出结论，只要API的质量不得到提高，软件的采用率也就不会上升。
（伯乐在线配图）
什么是好的API
什么是好的API？什么是程序员需要的？API需要什么质量去吸引程序员？我们的设计努力应该付出在哪里？
第一点：intuitive: 直观
什么是直观的？具体又如何实现？Wikipedia上解释直观（intuitive）“不需要刻意努力的理解”（understanding without apparent effort），Merriam Webster的解释是“不需要刻意有理推导来获取知识或者认识的力量”(“the power or faculty of attaining to direct knowledge or cognition without evident rational thought and inference”)。细说开去，我们可以用一个博士学位来讨论人类的认知过程，我们就不展开了。就API设计来讲，intuitive design就是站在使用者的角度，保持逻辑一致。
第二点，simple: 简洁
这个会在以后的博文里面具体展开。这里我们就说一个纲领：需要平衡复杂的功能和简单的用户界面。
第三点是 easy to understand, remember, and use 易于理解、记忆和使用
这是任何专家都会给出的建议，但是实际操作却很难自始至终做到这点。尽量使用程序员们熟悉的逻辑和概念，用他们的语言(逻辑和语法)和他们对话，尽量减少引进新的概念和规则。尊重他们熟悉的命名方式，这样可以帮助他们记忆。这些减少刻意学习和使用的设计理念在API设计中很重要，因为它直接决定了开发人员适应API的速度和程度。
简单适用：程序员没有太多时间去评估一个API的好坏去决定是否使用。大多数时候，我们就试用两个方法，看看好不好用。API设计应该鼓励试用：核心情景必须能被简单采用，而且要有实例(sample code)来帮助采用。其二，API要安全(safe)。这个包括两点，一是本身那个情景(scenario)要稳定。其次，如果出现问题，错误报告要全面、明确。
最后一点：documented 文档备案。
拿到新的API，我们程序员会直接动手，而不是读说明书。如果没有人读，APIs到底需要文档吗？动手是浅尝辄止，我们叫了个方法，然后它做了意料之中的事情，至于它有可能会出现什么问题，然后有什么解决方法，或者同样的事情，是否有更加有效的方法完成，一行程序是不能了解的。这个就是为什么我们需要文档，全方位、多角度的解释（Redundancy），不是简单的重复同一种内容(repetition)。
特定功能性API(purpose-made APIs)
好的API是设计出来的。以上所列举的API的特性和优点不会自然流露在程序里面，把一组能被重复使用的独立函数放在一起不是一个好的API。软件与软件之间的界面会在独立板块的结界出现，但是这些界面如果不是结构上设计好的，他们放在一起不会是好的API。这个不是因为程序员的个人技术好坏，而是实际操作过程中容易迷失全景的概念。并且这样生成的API很难维护，每次更新或者改错都会引出新的问题。Erich Gamma说过“好的API不会是偶然的发生，而是刻意的出现。他们是一笔巨大的投资”。API设计应该作为一个单独任务，从实际写程序的过程中独立出来。设计出来的APIs是purpose-made APIs. 他们应该包括文档备案(documentation)，实例(code samples)，教程(tutorials)和单元测试(unit tests)。他们鼓励不同的采用方式，支持快速有效的用户端，如此才能与时俱进。
最后，正如 Joshua Bloch 所说：“公共API，就像钻石，恒久美，永流传。你只有一个机会去把她做好，请竭尽全力。”
（“Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best”.）
原文作者：Ferenc Mihaly 编译：伯乐在线 – 潘文佳
联系客服
