从商业角度探讨 API 设计

为 Web__ 设计、实现和维护 API__ 不仅仅是一项挑战；对很多公司来说，这是一项势在必行的任务。本系列 将带领读者走过一段旅程，从为API__ 确定业务用例到设计方法论，解决实现难题，并从长远的角度看待在Web__ 上维护公共API _。沿途将会有对有影响力的人物的访谈，甚至还有 API__ 及相关主题的推荐阅读清单。_

这篇 InfoQ__ 文章是 Web API从开始到结束系列文章中的一篇。你可以在这里进行订阅，以便能在有新文章发布时收到通知。

如今，API 已经成为了每个重要信息技术趋势的核心内容。移动设计、云计算、物联网、大数据及社交网络等应用都依赖于一个基于web 的界面与它们的分布式组件进行连接，为全球范围内的各个商业领域提供具有创新性和颠覆性的解决方法。智能电网（Smart grid）技术改变了能源行业的形态，联网汽车（Connected Car）解决方案则被视为自动汽车行业中的关键因素，亚马逊使得每个所接触的行业都产生了具大变化。在所有这些例子中，API 的使用既是催化剂，也是促成这一成果的主要力量。

由于API 对于商业的巨大影响，因此有关“API 的商机”的各种文章也是层出不穷。在开放性的互联网上，使用API 作为一种外部频道进行创新及盈利已经成为一种独特的商业模型。在由 Kin Lane 所创建的 API 传道（Evangelist）网站中可以找到关于这一话题非常全面的信息， Mehdi Medjaoui 则在最近的一篇帖子中用精练的语言对此进行了总结。然后，在跨科技领域的API 应用范围内，开放式API 模型仅仅表现出其实用性的冰山一角。实际上，Web API 的主要能力还没有从各种使用API 实现的解决方案中被发掘出来。从这种意义上说，API 的商机本身就是一种商业模式。

本文将从商业角度对API 进行全面的讲解分析，无论它是否是开放式并且公开发布的。我会谈到尝试用API 为你带来商业价值的重要性、分析在其中应该使用的数据类型、并学习Aamzon 及Twilio 的成功经验。希望这些内容能够有助于你打造有用的、并且可用的API。

评估API 的商业价值

API 的通用商业价值是可以进行评估的。一切从数据出发，许多公司及组织将他们的数据视为一种负担，毕竟服务器和存储方案的价格不菲。但在如今这个越来越趋向于电子化的世界中，很显然，数据也是一种宝贵的资产。数据提供了各种宝贵的客户资料，它能够产生可辨别的商机与新的收益方式。“大数据”狂潮正是追求通过海量数据的分析处理电子中的混乱信息。即将到来的物联网（IoT）爆炸将使数据的规模呈现指数级的增长，因此对各个公司来说，对于数据进行正确的分析就变得至关重要。

对于一家公司来说，数据到底是一种资产，还是一种负担，是取决于以下三个方面的：即数据的可访问性、准确性和可应用性。每个 Web API 都在某种程度上提供了某些数据的可用性，而有价值的 API 则为公司的核心商业数据提供准确的数据。这使得公司能够达到一种我称之为“Data-Enabled Disruption”的迭代发展模式，在下文中我会为这种模式做出解释。此外，在决定应该由 API 暴露哪些数据及服务时，以及如何实现这些 API 时，这三个方面的数据属性也提供了一种有效的方法论。

数据可应用性

• 这些数据是否有助于我的商业目标决策？
• 这些数据是否能够为我的业务带来独特的价值？
• 如果我将这些数据公开化，是否能产生某些商机？

数据准确性

• 当前提供的数据时效性如何？
• 数据的来源是否可靠？
• 数据是否由期望中的用户所使用？是否用于正确的目的？

数据可访问性

• 哪些数据是可以由编程方式获取的？
• 有哪些不同的方法可以获取这些数据？
• 开发者创建使用这些数据的应用难度有多大？
• 数据访问的规模能否满足客户的需求？

如果从 API 的角度对这套方法论进行验证，那么可以将数据的这三种属性合并为 API 的两种属性：

1. “实用的 API”提供准确与合适的数据
2. “可用的 API”提供可访问的数据

显然，最有价值的 API 应当满足实用与可用两个条件。不过，为了更进一步定义这些 API 属性，让我们分别来进行一下分析。

实用的 API

在开发 API 时，人们最常见的一种错误就是认为所有的数据都是有用的。有一种流传甚广的奇谈是这么说的：一旦你拿出这些数据，神奇的开发者们就会出现在你面前，他们会撒下一些具有魔力的粉末，让你的收益得到增长、涌现各种创新的想法、并打通各种商业渠道。但仅仅使用 API 和开放数据是不足实现这几点的。正是这种“媒体即讯息”的想法造成了过去十多年间在企业整合这一领域中出现了大量失败的 SOA 尝试。某家超大型企业曾经花费了 5 千万美元以上的资金企图打造一个 SOA 及私有云的项目。而当我问及他们打算为哪些客户提供什么样的服务时，他们立刻就哑口无言了，因为他们只关心如何打造基础设施。毫无疑问，这个项目最终失败了。

从好的方面来说，如果能够使用正确的 API 公开正确的数据，那么就能够实现收益的增长与创新的进步。Google Maps 利用 Google 压倒性的占有率所提供的基于 API 的服务，正好填补了市场在这方面的空白。由于这一服务相当便利，因此 Google 可以将它作为商业产品收取大量费用。由于 API 的存在，Google Maps 也成为了早期 iOS 平台上的常驻应用，而苹果自己推出的替代品在一开始的反响就相当差，这反而突显了 Google Maps 的价值。由 Facebook 与 Twitter 领衔的社交网络平台的发展与成功也离不开 API 的应用，正是后者促进了他们的 web 链接数目与移动平台上的应用实现。实用的 API 甚至对联邦竞选活动产生了深远的影响。

Amazon 的 API 故事

正如我在文章开头所说的一样，企业从 API 中获得商业成功的潜力远远大于开放 API 在表面上的能力。Amazon 就充分利用了这种潜力，其实它们的 API 最初只是在公司内部进行使用。API 为 Amazon 所带来的这种长远的成功在任何一个行业中都找不出相似的案例。Amazon 为使用其 API 的客户提供了宝贵的经验，帮助这些企业使用它们的 API 获得商业上的成功。

Amazon 为我们所上的第一堂课，也是最为明显的一堂课，就是它是怎样将 API 设计为产品与解决方案的构造块的。Brad Stone 在由他编写的书籍中专门用了一章的篇幅来描述Amazon 是怎样将基础API 发展为它的技术航母的。Kin Lane 也对Jeff Bezos（Amazon 的CEO）是怎样从固执的陈旧观念中慢慢转变，让Amazon 最终提供编程式访问能力的过程进行了精彩的总结。按照这些报告及一些其它资料所说，产品经理必须指出他们的提案中的商业价值的最小公分母。随后技术团队就会利用这些原始数据创建API，将这些商业价值提供给其他开发者，让他们继续创建整个方案中剩余的部分。背后的逻辑在于这些商业价值的增长能够直接使用，并且能够非常容易地进行结合，以进行未来的产品开发。这就是为什么Amazon Web Services 能够如此迅速地发布及改善：Amazon 对它们的基础设施服务都进行了API 化，从而优化了扩展基础设施能力的过程。AWS 的产生过程就是将这些内部功能转化为外部产品。正如你所见，Amazon 不仅仅保证了他们所提供的API 提供了有用的数据，而是走得更远，他们将这一原则进行了倒转，保证了整个解决方案中的每一份数据都能够由API 方式进行提供。

Amazon 在 API 方面的另一个例子是它如何使用基于 API 的方式进行有价值数据的收集、分析、改善以及分布的。当早期的 Amazon 还以在线书籍的销售为主营业务时，Jeff Bezos 对于 Amazon 的核心价值观念就有了清晰的预期：“我们不是通过销售盈利，而是通过帮助客户进行采购决策而盈利。”他始终保持公司的运营与这一核心价值观相一致，从而产生了策略方向的各种改变，例如提供个性化及扩展频道等举措。实际上，从以上核心价值观中就可以看到，正是这些适用的、准确的、并且可访问的数据为客户的决策作出了引导，让Amazon 一步步走向成功，而不是靠着在线图书或其它商品的销售获得的成功。在Amazon，正是API 将数据进行不断积累与改进，这一周期性的过程刺激了Amazon 的成长。我将这个360 度的周期称之为数据革新“Data-Enabled Disruption（DED）”，下图是我对它的总结：

DED 的成功运用，使得 Amazon 得以击败无数竞争对手。由于在整个数据生命周期的每一步都应用了 API，因此 Amazon 能够持续地改进数据的准确性、适用性及可访问性。

我们最后将学习 Amazon 是怎样在公司的战术产出和策略定位之间进行平衡的。自从 Jeff Bezos 认识到万维网的潜力，并制定出“提供所有商品的商店”这一愿景之后，他就非常清楚地认识到这种平衡的重要性。Bezos 认识到他先要从一个较小的目标开始，经过对市场进行一番分析之后，他认准了在线图片销售这一领域，它的发展时机已经成熟，并且供应链也十分理想。在随后的发展中一方面保证快速的执行，一方面始终不忘对未来的愿景设计，这种齐头并进的发展理念已经成为了 Amazon 文化的一条根深蒂固的宗旨。每个解决方案既要为公司产生价值，也要为未来的发展铺好基石。基于 API 的交付方式就是实现这种原则的一种理想的方式，因为 API 不仅能够服务于新的应用与服务，也能够为未来的各种用例打好基础。这种迭代式发展的方法论促进了亚马逊业务的不断发展（见下图的说明）。

（单击图片以放大）

图片中的每个服务都对应着一套外部的API ，同时，每套API 都是建立于已经完成的API 基础之上的。任何一家打算纵向或横向进行业务扩展的公司，都可以认真参考一下Amazon 是如何打造一套有用的API 的方法：持续地收集和获取可用的数据、使用API 作为这些数据的通用访问点、只交付短期内有用的数据，同时兼顾长期的发展计划，以此作为公司的竞争力进行不断扩展。

可用的API 及API 设计的重要性

尽管Amazon 在这方面取得了令人瞩目的成就，并且API 在公司的成功中扮演着重要的角色，但Amazon 的API 仍然没有被公认为设计最优秀、使用最简单的API。随着 API 数量的爆炸性增长，并且对于 API 的必要性的认可度也在不断增加，API 的可用性正是让那些在行业中处于支配地位的公司，甚至是那些仅仅打算用API 建立创新性服务的创业公司能够获得成功的关键因素。

移动设备的出现及IT 的消费化趋势，是对于传统的企业级应用开发的一次全面转变。在过去，普遍存在着各种功能单一的终端主机、客户- 服务器系统、以及最近出现的web 的分布式布局。我过去也曾谈及这种我称之为“层的脱落”的现象，即将业务从n 层的web 模型转向以API 为中心、以移动和云为优先的设计。这种转变也包括了代码开发从Java 企业版转到JavaScript 及其衍生语言的情况。所有以上这些都表明，正有一波新的开发者，他们将逐渐成为开发新企业级解决方案的主力。这些开发者们习惯于主动寻找有什么API 可以满足他们所需的功能。当前的公司应当预计到这种转变的发生，并迎合新一代开发者的需求，方式就是拥抱 API 的可用性。

让我们看一下电信业的情况。多年以来，各大电信巨鳄们都在处心积虑地想要打倒竞争者，同时也在积极地推出各种跨网络的增值服务。这个行业在过去的 15 年间产生了巨大的革新，包括 VOIP 的出现、业务及运维服务的整合，以及移动设备服务的革命。在种种革新的进程中，API 都扮演了重要的角色。即使在传统电信服务方面仍占据领先地位，但这些电信巨鳄们也难以从这波革新浪潮中受益。而当他们试图与 Parlay X 及 OneAPI 等创业公司进行合作时，他们遇到的困难比这些小公司更多， Alan Quayle 在他的一篇文章中就总结了这一现象。如果这些大佬们都难以抓住这次机遇，又有谁能做得到呢？

创建于 2007 年的 Twilio，其发展目标就是为客户提供易于使用的语音及文字消息服务，并且完全在云端进行托管。他们一开始就计划打造这样一个平台，并且意识到 API 会成为他们第一位的业务方向。SMS 和 VOIP 服务固然很有用，但为了与电信巨鳄们展开竞争，他们所需的不仅仅是一些便利的电话服务而已。

Twilio 最关键的洞察力在于：他们已认识到所提供的服务的第一批客户并非那些调用 API 的应用的终端用户，而是那些负责开发这些应用的开发者本人。他们也知道，移动端应用的增长速度必然是最高的。因此，他们定制了一套指标，用以衡量这批客户对 API 的满意程度。除了传统的终端用户统计数据，例如端到端的 API 调用响应时间之外，他们还额外对新开发者注册这套 API 所需的时间进行衡量，并且设定了很高的目标。这套指标的设定改善了 API 的可用性，从而为 Twilio 建立了对于各大电信巨鳄的领先优势。当应用开发者们在为应用的开发选择 SMS 或 VOIP 提供者时，Twilio 的这套响应迅速的轻量级服务就明显比起竞争们胜出一筹。有了这套实用的 API 之后，Twilio 就可以理直气壮地对服务收取费用，通过客户的每次 API 调用的付费实现盈利。也正是因为这套实用的 API，Twilio 提高了公司的名气，同时也增长了公司的利润。

电信之外的各个行业也对数据革新的方向准备就绪了。就拿 Ingenie 来说，这家保险业的创业公司在基于精算的定价方法方面推陈出新，对于 16-25 岁这一阶段的年青人会进行适当的惩罚。他们通过在每台汽车里安装的一种专利智能设备对每个驾驶员的数据进行收集，随后依据这些数据为这些驾驶员们提供相应的保险折扣。实用的、可用的 API 使得 Ingenie 能够实现数据带来的革新，让他们像 Twilio 一样征服了整个保险行业。

实用的、可用的 API 指南

在此进行一下总结，要确保 API 的成功，可以通过以下几个步骤来实现：

• 确保你的 API 与公司的策略相一致
• 在 API 中包含可访问的、准确的并且适用的数据
• 确保你的 API 是实用的，并且可用的
• 学习 Amazon 的方式，建立一种规范的文化，迭代式地实现数据带来的革新
• 学习 Twilio 的方式，创建一种优秀 API 开发者体验，从而使你的业务更胜于其它各大竞争者。

只要按照这套指南的方法，你的 API 终将为你的业务带来巨大成功，并成为这方面的典范。只有你能够最好地判断怎样为客户提供实用的 API。此外，也请各位拜读一下本系列中的其它各篇文章，它们会为你实现实用的 API 提供许多宝贵的建议。

关于作者

Matt McLarty(@mattmclartybc) 是 CA Technologies 公司的 API Academy 部门的副总裁。该部门为各公司提供 API 策略、架构及设计方面的专家指导，以帮助他们在电子经济时代茁壮成长。

为 Web__ 设计、实现和维护 API__ 不仅仅是一项挑战；对很多公司来说，这是一项势在必行的任务。本系列 将带领读者走过一段旅程，从为API__ 确定业务用例到设计方法论，解决实现难题，并从长远的角度看待在Web__ 上维护公共API _。沿途将会有对有影响力的人物的访谈，甚至还有 API__ 及相关主题的推荐阅读清单。_

这篇 InfoQ__ 文章是 Web API从开始到结束系列文章中的一篇。你可以在这里进行订阅，以便能在有新文章发布时收到通知。

查看英文原文： Article: A Business Perspective on APIs