【APIs — A Strategy Guide】第一章 API的机遇

翻译/刘仲阳

14年跟设计组的兄弟一起把《APIs — A Strategy Guide》翻译了一下,时间过去快两年了,两年的时候对API的理解又加深了一些,把当时翻译的东西拿出来看了看,感触颇深,一方面是当时主要聚焦在设计工作这块,对书里面很多理念无法理解,现在再看已经明朗许多,另一方面,团队两年下来有兄弟换了部门,也有兄弟离开了公司,想想兄弟们辛辛苦苦的工作成果,还是要拿出来给大家分享一下,就此对译稿在开发者社区分章节发布,因为发布前需要再对内容进行核对,计划每周发表一篇。

因为都是理工科出身,翻译功底和文字 功底上还是有所欠缺,我们尽量将内容自己理解后用文字来描述,跟原文不一定能字字对应。

—————————————————————————————————————————————————

第一章     API的机遇

翻译:刘仲阳

API是商业成功中的重要元素,并且正变得越来越重要。诸如Google、Facebook、Apple和twitter这些先驱公司已经向公众展现出很好的技术方案,用以转变现有商业模式并创建新的行业。这些公司的主要成功在于API将用户、设备与基础平台联系在一起促进公司各自的业务发展,并在背后将这些公司联系在一起。

世界正在改变,仔细想一想下面这些例子:

?   Salesforce.com(CRM系统公司)通过向合作伙伴开放核心服务并借助合作伙伴的创新和扩展能力建立了一套巨大的、包含大量合作伙伴的生态系统。现在,Salesforce API的访问量比Salesforce网站还要大。从2011年中期开始,Salesforce 60%以上的流量都来自于API

?   Amazon通过Amazon Web Services(AWS)提供众多的API用来开放自己的核心计算设施的能力。现在通过AWS服务的宽带用户,比其全球所有网店服务用户加起来还多。

?   Twitter是最明显的例子,整个业务都是基于API和一整套开发者、应用生态系统。

?   通过将流媒体传送到不同的设备,Netflix改写了我们看电影和电视节目的方式,使得录像租赁、有线电视等相关行业被颠覆。而开放的API使Netflix能以很经济的方式去支持这些不同的设备。

?   NPR的数字媒体部门的工程文化已经注入了API(开放理念)。API驱动着网站、移动应用程序,以及其它形式的节目发行和合作业务。API也改变了NPR与其成员站的关系,以及与他们共享内容的方式。

再来想想这些行业动向

?   智能手机销量在2011年初超过了新增的个人电脑销售量,摩根士丹利预测,到2012年底,联网的移动设备数量会超过PC。CTIA(无线行业协会)已经确认,在美国无线设备的数量比人还多。

?   分析师们都在竞相预测在于未来将会有多少移动设备。GSM协会预计,到2020年将有200亿在线的移动设备,爱立信首席执行官卫翰思(Hans Vestberg)预测则是500亿。与此同时,思科公司负责新兴技术组的高级副总裁Marthin De beershuo则预测到2020年这一目标将超过一万亿。

?   思科预测到2015年前,每年通过个人电脑产生的互联网流量将持续以33%增长,但通过非个人计算机设备产生的流量增长将是前者一倍以上。

?   在撰写本文时Facebook占据超过25%的互联网页面浏览量,其API驱动着Facebook产品和其整个生态系统。

?   在美国黄金时段,超过30%的互联网流量来自Netflix流媒体数据,这些数据都是通过Netflix的API来分发和管理的。

这些统计不单单表明整个互联网流量的暴增,也表明了流量分布向移动应用和设备转移的重大变化。看看这些加速变化的趋势,不难想象,API在几年内很可能会成为引爆你们互联网流量的动力。

我们为什么写这本书

作为本书作者,我们从实战经验中弄明白这个课题。

Daniel Jacobson(译者注:本书三位作者之一)领导开发了NPR的内容管理系统,并从系统中提炼出API。NPR API现在是NPR数字分销战略的核心,将NPR的能力转换后发送给使用不同平台的听众。

今天, Daniel领导开发了Netflix 的API,API战略是Netflix推进流媒体服务的关键路线。通过这项服务Netflix有能力向成百上千的设备提供丰富的视频体验,并且显著提升了开发新功能并交付给新设备的效率。通过这个项目,Netflix的用户有了突飞猛进的增长,一年时间内,API访问量增长,从每月不足十亿个请求增长到每天十亿个请求。

Greg Brail(译者注:本书三位作者之一)写本书时,主要是基于他在apigee担任CTO的经验,在那里他帮助别的公司实现了大量的API项目。 作为CTO,他还借鉴apigee团队的智慧来完成本书, apigee的团队接触过数以百计的开发者,并从数百家公司的API项目中学得了不少经验。

我们写这本书来帮助人们理解API的潜力。我们希望你参深入进去认真的创建一个API。这本书不是一本编程手册,而是最佳实践,你需要了解创建一个API相关的机遇和策略问题。

这本书还将向企业高管和技术人员介绍API的广阔机遇。可以肯定的是,API包括了大量的技术元素, 而经常被忽视的是其对业务的影响。

这本书是介绍关于如何从业务的角度考量API,如何使API对你的业务产生积极的影响。

我们也想告诉你,当你决定开发一个API时候你需要了解些什么方面的知识。提供一个API的意味着什么?不仅仅要从技术角度看,还需要从经营策略,法律和授权方面考虑,并且需要考虑与合作伙伴的关系问题等。

我们要说明的是,API正对世界各行业产生深远的影响,现在是采取行动的时候了。

与其他许多只着眼于大互联网公司对外公开开放API的讨论不同,这本书还强调私有API的应用,我们相信这会比你们经常看到的众多的开放API项目产生更大的影响。

作为本书作者,我们必须同时关注技术和业务上的内容。为此,我们希望教育有创新意思的管理者和技术人员如何把API融入到他们的业务上下文中。

在本书中,我们将讨论:

?    API的商业机会

?    一些公司使用API来改变他们的业务,甚至在某些情况下改变他们的行业的例子

?    API商业模式

?    一个API价值链是什么样子以及如何开启不同的价值链

?    制定您的API策略的注意事项,回答相关(的问题)和异议

?    API设计问题,尤其是如何使开发者更容易选择

?    如何处理API的安全问题,包括OAuth问题

?    运营一个API业务的法律问题,包括隐私和个人数据的(使用)权利问题

?    API大规模应用的注意事项

?    如何看待指标,如何衡量你的API程序

?    参与开发人员(讨论)并建立社区推动(开发人员)使用你的API"

总之,这本书提供了一个通过API来改变你的业务的思路。

本书读者对象

在API技术方面有一些的相关的书籍,包括Rest、OAuth、XML、JSON等等。这本书不是为了与这些书竞争(技术上)。事实上,在不深入钻研技术方法的基础上几乎是不可能说明白API的, 这本书不是针对那些构建API或直接使用API的技术专家。更确切地说,这本书是专为那些需要战略上决定是否需要一个API提升自己的公司的人写的。

这本书的目标受众包括C级别高管成员,业务开发团队、产品经理和技术宣讲者。当然,这本书受众也可以包括很多较高层次的技术专家。

什么是API

API是Application Programming Interface(应用程序编程接口)的缩写。API作为访问入口,供公司内的开发人员、合作伙伴或第三方开发人员访问数据和服务,用以快速构建应用程序,比如iPhone应用。Twitter和Facebook的API都是众所周知的例子。API又可以分为,面向所有开发人员开放的API、只针对某些合作伙伴开放的API,以及只提供给内部使用的API,用来帮助业务更好的运行并促进团队之间的协作。

API本质上是一个规范。有了这样的规范保证,开发人员被吸引并使用API,因为他们知道他们可以依赖它。规范增加了开发人员对API的信心,从而增加API的使用。因为规范将接口的定义文档化、明确了接口的一致性,并使接口的演进和变化变得可预测,这些会让API的生产者与消费者之间的沟通变得更加高效,

API与网站之间有什么不同

API与网站有着非常大的区别,网站提供信息的方式是即需即取。

公司向全世界发布信息供人们使用。网站对如何使用这些内容没有明确的规范或结构要求。如果网站上的内容更改,新访客访问的就是新内容。他们的浏览器并不会受影响,任何改变对用户是可见的。如果你对网站进行设计,唯一受到影响的是那些习惯了内容以原有特定的呈现方式的用户。

人类对视觉图像的匹配能力是非常强的,我们可以很快适应新的设计并找到我们所需要的内容。所以当用户喜欢的网站被重新设计后,用户也许会抱怨,但最终他们还是会适应这样的改变。

API则非常不一样,因为API是一种规范,程序都是基于这种规范进行开发的。程序不像人类那样灵活,它最不擅长的就是模式的匹配。如果你改变API规范中的任意一点点东西,对上层应用的影响可能就是一石激起千层浪。

我们对API的定义

技术定义:API是两个计算机应用之间,基于网络(主要是互联网)、使用二者能共同理解的语言进行“交流”的一种方式。

API要遵循规范,意味着:

?    API提供者详细描述API将提供什么功能。

?    API提供者描述功能何时可用,以及它何时可能发生改变并不再与原功能相兼容

?    API提供者应描述API中额外的技术约束,例如访问速度(次数)限制,如控制一个特定的应用程序或用户在指定的时间内(在给定的小时,天或月)使用API的次数

?    API提供者应概括在使用API时所涉及的额外的法律或商业约束,比如品牌限制,使用类型等等

?    API提供者设定使用规则,开发者必须在遵守这些规则的基础上使用API。

此外,API提供者可以提供其他一些工具,如:

?    API的访问机制和使用条款

?    API文档,用于帮助理解API

?    示例程序、开发者社区等资源,用于指导开发者使用API

?    有并API运行的健康状态和API使用情况的运营信息"

记住API的结构是规范的一部分。规范是有约束力的不能随意改变。

你应该把API当作软件产品来对待,考虑其版本控制,后向兼容、循序渐进的引入所有新功能。

应该在支持现有基线和保持必要的演进之间找到一个平衡点,这样你的API可以在遵循其发展计划的同时与你的业务一起发展。

这并不意味着API可以永远不能改变。相反,API作为一个在线产品,可以不断的改变以满足业务的需要,或服务于当前业务,以最大限度的提升业务效率。但这些只是实现层面的变化,而不是接口。如果做得正确,API的实现可以每天都变,甚至频率更高,但接口总是保持一致的。

但是API与网站之间也有很多相同点

API如同网站一样,需要24*7,一年365天不间断运行。开发人员跟网站的用户一样,没有太多耐心接受“每周六安排停机维护”这样的事情。所有这些说明在现有的企业技术基础设施上构建API将是一个挑战,因为业务系统往往被设计成一个具有一定运行周期的系统,运行一个周期后被关闭,直到第二天再启动(如银行系统),而API不可以这样设计。

成功的网站能够做到持续更新,改变其页面设计、对特性进行微调。这种持续的更新之所以成为可能,是因为网站是在线的实体,不需要对客户端进行修改即可完成,不需要在更新后通用用户进行软件更新。

API在这方面没有太大的区别。假设你的API保留后向兼容能力,API在引入新特性并改变现有功能实现的同时,不会影响现有的客户端程序。只要你坚持让开发人员按照API规范使用它,API的演进则可以按照“网络计划”而不是“企业IT时间表(译者注:原文为the api can change on a "web shedule" rather than on a "enterprise
IT schedule"。个人理解,按照这种方案我们只需要在网络上升级API,而不需要升级使用这些API的公司IT系统)
。这样就能演进出一个更好的、更多用户使用的API项目。

事实上,可以通过对应用程序和最终用户的行为进行分析来驱动API和网站演进。对于二者,好的设计和产品管理团队不断的检查分析数据,看哪些站点或API是成功的,哪些是失败的。这些结果应该融入到常规开发迭代中,随着时间的推移建立一个更强大的API或网站。

谁来使用API

我们把提供了API的公司或组织称为API提供者。这本书是主要针对API提供者的(或那些正在考虑提供API的)。

我们把使用API构建应用的人称作开发者。确实,很多人都对你的API感兴趣,包括企业主,营销大师、高管等, 但最终使用API构建应用程序的人是开发人员。开发人员是API的主要受众。

我们把使用开发者应用的人称作用户。他们是你API的第二受众,也是常常驱动你API决策的人,根据你的API提供的可用功能,你可能有特殊的问题需要声明,例如版权、合法使用等等,这些问题都与他们相关。

API的类型

我们看到两种类型的API:私有的和开放的。不管你在媒体中听到的什么,私有API还是更普遍。你知道如今全世界都在使用Facebook和Twitter的API。你可能不知道的是,这些企业广泛利用自己的API来构建他们的网站、移动应用程序和其他面用户的产品。我们的经验告诉我们,这些常见的公共API只是冰山一角。就像水下的冰山,大多数API是私有的、难以感知的,这些私有API在公司内部由员工和合作伙伴按规范协议使用。私有API的使用真正推动了API革命。不要因为公共API应用于苹果商店的例子而限制了你对使用API的方式理解,合作伙伴和内部使用的API通常更有价值。

大部分关于API的讨论都是假定API必须向公众开放才有价值。其实并非如此。我们相信私有API正对大多数公司产生革命性的影响,在很多情况下比公共API的影响要大得多。

《纽约时报》的API开始是作为一个私有API使用的,渐渐的改变了他们的业务。“《纽约时报》的API出现源自我们想让内部的内容管理系统需要更容易使用,这样我们可以从中获取更多我们想要的内容。”《纽约时报》编辑部开发人员德里克威利斯说。“API让更多人可以访问并创作有趣的内容,我们是自己的API最大的用户,但这不是偶然发生的。API可以在其他方面帮助我们发展业务:创建品牌知名度并帮助我们吸引人才。但从根本上说,它帮助我们更好的完成本职工作。”

让我们进一步讨论这个话题,澄清我们所说的公共API和私有API是什么含义。公共API是指所有人都可以在没有API提供者授权(超出协议的条款)的情况使用的API。私有API有众多使用方式,支持内部API工作开展或供合作伙伴使用。API提供者也应向使用私有API的大客户提供适当的法律条款。衡量API是私有的还是公共的主要还是与主业务息息相关,既不应参考API自身内容也不应参考使用API开发出来的应用程序。

公共和私有API最终仍然都是api。通常一个公司将从开发私有API开始并最终将其部分或全部开放出来、并可能设置一些额外的限制供公共使用。另一种情况,公司将推出公共API,然后意识到内部发展更为重要,并私有化使用,这最终使公司获得真正的商业利益。

例如,AccuWeather以向公众提供天气数据而著称,这使得大多数公众认为他们的API是公共的。但请记住:私有/公共API的区别在于其与合作伙伴之间的合约,而不与终端用户可获取的内容相关。和其他的私有API一样,AccuWeather的API被用来向公众提供应用程序。

对合作伙伴来说AccuWeather API是高度定制化的;这是一个关键的区别。AccuWeather技术主管克里斯·帕蒂说“我们的API有超过300个不同版本。这是我们的企业为每个客户、每个使用我们的API的公司定制的结果。我们迅速响应客户需求,这是我们的竞争优势。我们能够应对定制需求因此我们赢得了许多合同,比如提供数据服务和GPS定位功能。正因为我们的创造性且响应迅速,所以客户和我们合作。”

API提供者往往会从内部和外部选择不同的视角展现自己的营业资产。德里克·威利斯说:“我们可以提供多个版本的API支持多个使用场景或商业模式。我们可以有不同的API形态为不同的用户服务。例如,公共文献搜索API只能提供文献的片段,而内部文献搜索API可提供文献全文。”

为什么是现在

API已经到了该有所突破的时候了,原因有三点:

?    过程成熟度

API不仅仅是技术。如我们遇到的许多业务问题只是个人问题。API提供一种通用模式来帮助人们进行协作。"

?    自助服务

为什么开源项目能成功?虽然在众多讨论中都认为是可获取源代码是开源软件成功关键,但是另一种观点认为自助服务更为重要。只有一小部分的开发人员想要阅读或修改源代码。相反,开源码软件能取代商业软件是因为开发人员无需获得许可就可以获得软件并使用。API发布者从开源软件中学习经验。一个成功的API必须以提供自助服务为基础并且简单易用。

像开源项目那样,最好的API都有高人气的在线社区,无论是公司内部的或是大规模的开放的开发者社区(或者两者都有)。

在最成功的开发者社区里,最活跃的成员并不是为提供API的公司工作,而是他们想帮助API,因为API对于他们所做的事情是至关重要,而且他们喜欢通过帮助别人来发现API的价值。"

?    技术成熟度

几十年来尽管技术人员不断使用API,很少人意识到正是因为有了API,像Twitter、Netflix和其他网络服务才持续迸发出活力。

最终人们看到的是巨大的流量,但它不是网络流量,而是API访问量。

像Google, Amazon, Twitter, Sears, Alcatel-Lucent这样的公司和成千上万的公司都在使用API改变他们的业务。"

简而言之,科技博客作者Robert Scoble 通过定义三个时代来总结我们现在处于什么阶段:

?    1994年的网络是“给我一个地址和一个页面”的时代

?    2000年的网络是“让我的页面与人互动”的时代

?    2010年的网络是“摆脱页面,让API与人联接”的时代

我们相信,这意义深远的转变将继续,多了解一些对你非常重要。第二章将讲述API作为一种商业策略将产生什么样的推动力。

(更多华为资讯请关注华为开发者社区,华为自己的对外开放门户:http://developer.huawei.com/cn/ict/ ,不要问我叫啥,别人都叫我雷锋)

时间: 2024-11-05 22:55:45

【APIs — A Strategy Guide】第一章 API的机遇的相关文章

ASM学习笔记--ASM 4 user guide 第一章翻译

第一章 介绍 1.1动机 程序分析.生成和转换是非常有用的技术,它具有以下的应用场景: l  程序分析(包括从简单的综合性分析到一个全面的语义分析)可以被用来寻找潜在的bug,发现未使用的代码,进行工程代码的逆向. l  程序生成被用在编译器当中.这包括传统的编译器,也包括为分布式编程使用的stub或skeleton 编译器,即时编译器等 l  程序转换可以被用来优化或者混淆程序,为程序插入debugging或者性能检测代码,方便面向对象编程等. 所有这些技术可以被用到任意的编程语言,但是难易程

APIs — A Strategy Guide】系列之二 把API作为你的商业策略

翻译/张志高 如果你身处技术界, 你不会怀疑API对业务的显著影响,否则,可能有点难以理解为什么API会跟你的业务有关系. 在商业领域API每天都在快速增长,本章节的论点应该能帮助不在科技界的人了解API的重要性,同时提供一些论据使其相信采用API策略的价值. 今天,API消费模式正在急剧增长,为什么呢,主要是应用程序和移动设备快速增长.根据De Beer的估计判断,在2020年,应用程序和连接设备正迅速从十亿级增长至万亿级别.很多公司都发现他们的客户正快速抛弃基于浏览器的web应用.如果你想继

【翻译】jdbc developers guide and reference:第一章

 ************************************************************************   ****原文:blog.csdn.net/clark_xu 徐长亮的专栏 ************************************************************************ 1.1 读者: 具备java,plsql,oracledatabases基础知识 1.2 相关文档: 关于oracle ja

《ASP.NET Web API 2框架揭秘》第一章 概述【样章】

<ASP.NET Web API 2框架揭秘>(详情请见<新作<ASP.NET Web API 2框架揭秘>正式出版>)以实例演示的方式介绍了很多与ASP.NET Web API相关的最佳实践,同时还提供了一系列实用性的扩展.本书详细讲解了ASP.NET Web API从接收请求到响应回复的整个流程,包括路由.Http Controller的激活.Action方法的选择与执行.参数的绑定与验证.过滤器的执行和安全等相关的机制.除此之外,本书在很多章节还从设计的角度对AS

网页音频API 第一章

第一章:基础这一章将介绍如何着手开始学习web音频api.哪些浏览器支持音频api.如何检测音频api是否可用.什么是音频图.什么是音频节点.如何连接各音频节点.一些基础的节点类型,最后将介绍如何加载声音文件和播放声音. 网页音频历史简介第一种在网页上播放声音的方法是通过<bgsound>标签实现的,当用户访问网页的时候,该标签能让网站作者自动播放背景音乐.这个特性只能在IE浏览器中使用,并且该特性从未被标准化或被其他浏览器采用.网景公司用<embed>标签实现了一个相似的特性,并

《windows程序设计》第一章,建议想学API的每天看一章

开始 壹佰软件开发小组  整理编译   本书介绍了在Microsoft Windows 98.Microsoft Windows NT 4.0和Windows NT 5.0下程序写作的方法.这些程序用C语言编写并使用原始的Windows Application Programming Interface(API).如在本章稍后所讨论的,这不是写作Windows程序的唯一方法.然而,无论最终您使用什么方式写作程序,了解Windows API都是非常重要的. 正如您可能知道的,Windows 98已

第一章 Codec Engine概要

本文翻译自TI的手册,该手册是学习GPP+DSP开发的金典文档,希望对各位入门有所帮助,有理解不当之处望请赐教. Codec Engine Application Developer User's Guide Literature Number: SPRUE67D Codec Engine 应用开发使用手册原文参见: http://blog.csdn.net/dyzok88/article/details/42154487 后期会更新<第二章 Codec Engine安装和设置>. // 正文

iOS 6 By Tutorials ---第一章--【第一弹】-【翻译】

iOS 6 By Tutorials(pdf 文档)  By the raywenderlich.com Tutorial Team 备注:本人没有怎么翻译过技术型的文章,慢慢翻之.---这本书总共是27章, Chapter 1:Introduction  --第一章:入门介绍 iOS 6 introduces an abundance of great new APIs and technologies that all iOS developers should learn – from A

ASM学习笔记--ASM 4 user guide 第二章要点翻译总结

参考:ASM 4 user guide 第一部分 core API 第二章  类 2.1.1概观 编译后的类包括: l  一个描述部分:包括修饰语(比如public或private).名字.父类.接口或者注释区域. l  类中每个域声明的部分. l  类中每个方法以及构造函数声明的部分.也包含了方法编译后的代码,它是一系列Java字节码指令的形式. 编译后的类结构如下: 2.1.2内部名(internal name) 类或者接口使用内部名,内部名就是类的全限定名,即带斜杠的全称. 例如,Stri