理解API的设计过程

　　在你手动设计之前，你应当了解为什么要设计这个API，如果在这方面需要帮助，有许多现成的资料可以参考。不过，定义你的动机仅仅是第一步，真正的诀窍在于直到实现为止，始终保持进行正确的设计决策。

　　成功的API设计意味着要设计出一种接口，让它的使用方式符合它的目的。作为API设计者来说，我们所做的每个决策都会影响到产品的成败。设计过程中需要做出一些重大的决策，例如API所使用的传输协议、或它所支持的消息格式。但除此之外，还有许多相关的次要决定，例如接口的控制、名称、关联以及次序。而当你将所有的决策集中在一起时，它们将带动API的使用模式。如果你能够做到每个决定都是正确的，那么这种模式将对API产生完美的支持与促进作用。

　　如果你要做出一个正确的设计决策，很可能会先做出一个错误的决策，并从中吸取经验教训。实际上，你很可能会在多次犯错之后才能够接近正确的决策。这也正是迭代的关键所在，因为没有人能够做到一次成功，但只要有足够的机会，你就能够做到接近完美。

　　通过迭代方式进行API设计，这一点说起来容易，但在实际应用中做到这一点并不简单。我们所面临的一个常见的挑战在于，在某个API发布之后再进行变更是非常困难的。事实上，对一个使用中的API进行变更的代价很大，并且伴随着很大的风险。或者借用Joshua Bloch的说法：“公开的API就像钻石，它是永恒不变的。”

　　处理这一问题的一种方式是在每次变更时不要破坏现有的接口，这是一种好习惯，也是优秀API设计的一个主要原则。但有些时候，破坏性的变更是不可避免的，而基本层面的设计变更尤其具有侵略性。

　　换种思路，我们应当在接口发布之前就做好这些变更。在理想的情况下，在变更的代价变得高昂之前，就应该消除易用性与设计方面的问题。当时，只有在首次发布之前做到尽早开始迭代，并保持频繁的迭代，才能够找到并修复这些问题。

　　迭代式的设计过程

　　在每一次迭代中，我们都得到了一次对设计候选按其使用情况进行评估的机会。举例来说，开发者是否能够通过使用我们创建的产品实现他的工作目标?这个接口真的能够实现吗?如果我们要求他人使用这个API，他们又会有什么样的感受?

　　通过设计与实现多个接口而不发布它们，应该能够实现最佳的API设计。通过对每个接口进行审查与测试，我们将对于如何改进最终产品具有良好的洞察力。

　　但是在实践中，这种壮观的迭代式设计是不可能实现的。没有几个人能有足够的时间、金钱或耐心去不断地设计与实现一个个可以运行的API。对于任何具有一定复杂度的接口来说，这种方式的迭代式设计会占用你过多的时间。

　　一个更合理的方式是在设计过程的早期就进行迭代，这些早期的设计应当具有足够的细节，可展现改进的最佳时机，但又无需过度设计而导致实现的困难。随着时间的推移，我们可以逐步地增加细节度(或保真度)，并最终得到一个完整的实现。

　　这种逐步推进的设计过程在设计界已经非常流行了，它通常被分解为三个重要的阶段：

　　草图设计

　　原型设计

　　实现

　　草图设计的强大作用

　　草图设计是设计方面的一种普遍行为。著名建筑师Frank Gehry的草图可谓天下闻名，以至于诞生了一部专门描述这些草图的电影。他的许多建筑项目都是从在一叠纸上所画的一系列草图开始的。Gehry总会画上几百张这样的草图，每一次都向良好的设计更靠近一步。

　　交互设计师Bill Verplank将草图设计描述为设计过程中必不可少的第一步。Bill Buxton还专门写了一整本书，用以介绍草图设计方法对用户体验设计的价值，并认为它的关键特征在于它的可弃性、而且在所有探索方式中是成本最低的一种。

　　将草图设计过程包含在API设计过程的早期阶段，让我们有机会体验接口的概念模型。这不仅是一次定义我们脑中已有的想法的好机会，也让我们有机会探索新的道路，并且提出“如果……会怎么样?”这样的问题，并逐步走向真正的创新。

　　优秀的草图应当是易于创建、并且可以任意丢弃的。如果创建这些草图花费了许多时间、或是难度太高，那么你就难以丢弃它们。这种可弃性非常重要，它让我们有机会承受住风险。

　　我们可以通过草图设计尝试不同类型的接口风格，并捉住那些在我们脑海中时而闪现的抽象概念。一旦这些思想具体化，我们就能够对它们进行审查及讨论。在过程中决定我们喜欢或是不喜欢某个特定的概念，然后在消化了这些知识后再次启动这一过程，并绘制新的草图。

　　对于设计团队之外的用户来说，他们很少会对草图进行评估。不仅是因为过早地对假设进行验证是没有价值的，并且在实际的项目中能够进行的用户测试次数是有限的。通过真实的用户对每种草图都进行测试的设想代价过高，而这种方式的收获是非常有限的。

　　使用档案进行草图设计

　　在进行API的草图设计时，使用档案(profile)或元语言(meta language)是一种非常实用的方式。档案提供了一系列的概念，可用于草图的设计。一个优秀的档案可以类比为框与线，通过它创建系统图的多种草图。这些元素是设计师与评估者都能够理解的内容，它让快速地开发草图变得更简单。

　　实际上，着手进行API草图设计过程有一种好方法，就是定义接口中最明显的单词列表。有哪些单词是用户必须知道的?哪些单词能够最好地表达你的目标受众的目的与任务?通过回答这些问题，并创建一份接口的词汇表，将有助于你形成对该接口的一种早期草图。

　　档案的美妙之处在于，它为我们提供了一种正规化的方式以共享及重用这种类型的信息。举例来说，我们在开始设计时可能会从某个XML结构文档中提取出单词、从schema.org获取一份词汇表、或者从某个ALPS或RDF文档获取信息，这取决于我们的需求。

　　设计阶段的目标并非创建一份全面的词汇表，恰恰相反，早期的词汇表只是一个起点，我们可以从这一点开始绘制出其它类型的细节。我们可能会发现一个由20个左右的单词组成的列表就能够捕获接口的本质，这个列表就可以作为我们的起点。

　　这份词汇表为我们提供了一个基础，我们可以从它出发为API中的资源与关联设计草图，内容可以包括URI、资源名称、资源间的关联、链接文本以及其它结构化以及导航元素。请再次注意，没有必要画出草图的所有细节，我们的目标是表达出API里最重要的部分。

　　最重要的一点在于，最初的草图无需过于深入。比方说，请尽量避免在这一阶段就深入到错误流的建模，或响应消息元素的设计。这些部分可以稍后再加入，或者可以为它们进行专门的草图设计。

　　一份单独的草图无需反映出整个接口，实际上，为某些细节部分专门设计草图的方式可能更实用。举例来说，我们可以设计一个基本错误流的草图，它与整个API都具有相关性，或是设计一种响应消息格式的草图，这种格式可以应用到所有响应中。之后，在原型设计阶段，我们可以将这些思想应用到某个工作模型中。

　　更多资讯，请访问郑州软件设计教育机构