从商业角度探讨API设计

  为Web设计、实现和维护API不仅仅是一项挑战;对很多公司来说,这是一项势在必行的任务。本系列将带领读者走过一段旅程,从为API确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在Web上维护公共API。沿途将会有对有影响力的人物的访谈,甚至还有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提供许多宝贵的建议。

时间: 2024-10-02 10:03:02

从商业角度探讨API设计的相关文章

Web API设计方法论--比较完整的web api 开发过程

为Web设计.实现和维护API不仅仅是一项挑战:对很多公司来说,这是一项势在必行的任务.本系列将带领读者走过一段旅程,从为API确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在Web上维护公共API.沿途将会有对有影响力的人物的访谈,甚至还有API及相关主题的推荐阅读清单. 这篇 InfoQ文章是 Web API从开始到结束系列文章中的一篇.你可以在这里进行订阅,以便能在有新文章发布时收到通知. 设计Web API不止是URL.HTTP状态码.头信息和有效负载.设计的过程--基本上是

RESTful API 设计指南(转)

网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论.我以前写过一篇<理解RESTful架构>,探讨如何理解这个概念. 今天,我将介绍RESTful API的设计细节,探讨如何设计一套合理.好用的API

RESTful API 设计指南

RESTful API 设计指南 本人来源于:http://www.ruanyifeng.com/blog/2014/05/restful_api.html 作者: 阮一峰 日期: 2014年5月22日 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比

【转载】RESTful API 设计指南

作者: 阮一峰 日期: 2014年5月22日 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论.我以前写过一篇<理解RESTful架构>,探讨如何理解这个概念. 今天,我将介绍RESTful API

RESTful API 设计最佳实践(转)

摘要:目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息? 背景 目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完

RESTful API 设计最佳实践

1. 背景 REST(英文:Representational State Transfer,表述性状态转移)描述了一个架构样式的网络系统,比如 web 应用程序. 目前互联网上充斥着大量的关于RESTful API(为方便,下文中"RESTful API "简写为"API")如何设计的文章,然而却没有一个"万能"的设计标准:如何鉴权?API 格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完的时候,你

从研发人的角度评判怎样设计一个好的DCS系统

相信从事自动化或控制系统的同仁,应该了解Distributed Control System(简称DCS)的基本功能及其在工控行业的作用.从工程应用的角度,一个完整的DCS系统主要包括三个部分:HMI人机交互层.控制站层.仪表与执行机构层. HMI主要包括工程师站.监控站.历史站等,主要在具有较高稳定的PC上安装相应的软件构成.控制站层,主要实现相应的控制算法与逻辑,并通过相应的IO卡件采集数据和发送指令.仪表与执行机构,主要由各个厂家的智能变送器.电动机等组成. 由于仪表与执行机构,厂家众多,

(转) RESTful API 设计指南

原文: http://www.ruanyifeng.com/blog/2014/05/restful_api.html 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论.我以前写过一篇<理解RESTful

RESTful API 设计指南[转]

作者: 阮一峰 日期: 2014年5月22日 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论.我以前写过一篇<理解RESTful架构>,探讨如何理解这个概念. 今天,我将介绍RESTful API