API 的历史

Posted 2020-09-19 回声小站

原文出处： apievangelist   译文出处：灯下鼠

历史无处不在。 研究我们来自何方，有助于指引我们前行。科技的发展日新月异，但时常停一下匆忙的脚步，稍稍回顾一下历史，却总是有益的。 下面就让我们来看一看 API 的历史。

API 概念的出现，远远早于个人计算机的诞生，更不用说网络的诞生了。在公用数据处理的早期，为了一个应用能够与其它系统交互，开发者便已开始设计可公开访问并描述清晰的“接入点”。早在那时，这种做法作为一种准则，已是软件开发的主流理念。 但是，直到分布式系统的出现，乃至网络的降临，这些基础概念才淋漓的发挥出其重要性和惊人功效。

当我们回顾 API 的历史，会发现其中有一个阶段非常重要。 那是2000年左右，SOA(面向服务的架构)正在发展之中。API 的一种形式在企业应用中诞生。作为 SOA 伟大实践的一种，这种形式的 API 走出了企业应用的领域，在创新科技的世界里找到了更肥沃的土壤。

到了今天，我们能从技术角度，找出无数原因来解释为何 web API 能够在各种类型、不同大小的企业中获得成功，甚至也广受政府机构的欢迎。 但实际上，技术并非一切。web API 的成功，还要归功于很多其它方面的因素。这些因素大多并不那么抢眼，所以需要我们认真的研究历史，经过仔细观察才会发现为何那些 web API 的开拓者能够成功。

时至今日，我们还是要去学习过去十几年里的最佳实践。在对那些成功提供 API 的开拓者，包括 Amazon，Salesforce， Ebay，Twitter进行研究时，我们不能忽略任何重要细节。要知道，它们提供的 API 大部分还在运行着。

只要回头看去，我们就能清晰的看到很多模式。正是这些模式定义了这个行业。有些模式我们要学习，有些则需要避免。

商业

在第一次互联网泡沫破裂之后，众多电子商务平台立刻开始行动，寻找跨平台产品合作的方法。 在现有的 HTTP 架构之上构建的 web API，成为了当之无愧的最佳工具。

看到了这个契机，很多技术先驱开始着手为交易和商业管理定义最初期的 API。 从而拉开了大幕，开始了一场历时10年之久的变革。今天我们称之为 web API 的早期历史。

• SalesForce

2000 年 12 月 7 日， 在 IDG 2000 Demo 大会上，SalesForce.com 正式发布。

SalesForce.com 发布了企业级、基于网络的销售自动化系统。口号是“互联网即服务”。 XML API 在SalesForce.com 诞生的第一天，就是其重要组成部分。 SalesForce.com 强调用户需要在不同的业务应用系统中共享数据， 而 API 便有了最好的用武之地。

Marc R. Benioff 是SalesForce.com的主席和创始人。 他指出：SalesForce.com是第一个真正利用互联网来提供企业级应用软件的解决方案，而且成本仅仅是企业级软件的一个零头。

在企业级 web 应用和 API 领域，SalesForce.com是第一个云提供商。它所提供的产品，就是今日所谓的 “ SAAS, 软件即服务”。

在 web API 领域，SalesForce.com不仅是抢跑第一，直到今天，依然是领者。SalesForce.com在实时 API， 测试及部署上，还是保持领先位置。最近又在移动应用开发和后端即服务（BaaS）方面，开了先河。

• Ebay

2000 年 12 月 20 日，eBay 发布了 eBay Application Program Interface （API），同时还发布了 eBay 开发者计划。

最初的 eBay API，只针对一部分指定的合作伙伴和开发者开放。

eBay 宣称：

我们新的 API 是一场变革，极大改变用户在 eBay 上做生意的方式。也将大大提升网站上的交易数量。我们为 eBay 平台的开发者提供了应用开发工具，我们深信 eBay 将紧密的集成到很多网站中，包括现有的和未来的电商网站。

eBay API 的诞生之前，就已经有很多应用集成了 eBay 网站。有的合法，有的不合法。 此举公开发布，实际上也是顺势而为。

eBay API 的目的是为了标准化集成。也为了让合作伙伴和开发者，在围绕 eBay 生态圈开发业务时，更加容易。

eBay 是 web API 和 web 服务的先驱。今天，依然运营着最成功的开发者生态环境。

社交

当 API 驱动的电商平台，还在奠定基础，寻找使用 API 的最佳方法时，另一种崭新的技术平台出现了。 当时的 web 上，内容和短消息正当其时。这种新的技术平台，开辟了新的模式，完全以用户为中心，而且帮助人们进行网络社交。

在2003年至2006年间，诞生了这种社交平台。随之，通过 API，人们能够发布自媒体内容，能够共享 web 链接、照片和其它多媒体内容，于是社交平台风靡一时。 API 的崭新时代开始了。这个时代，金钱退后，一切都围绕着“连接”展开。

这些新型 API 驱动的社交平台，将技术推动到了新的全球高度。自那之后，一切应用，都将烙上社交的印章。而社交的功能，则由平台的 API 定义。

社交，是 API 行业错失的关键要素。

• del.icio.us

del.icio.us 是一个社交型的书签服务，用以保存、共享和查找 web 书签。Jousha Schachter 在 2003 年创建了这个网站。

del.icio.us 实现了一个非常简单的标签系统。 用户可以轻松的给自己的 web 书签定义标签，而且用可以理解的方式定义。 更进一步，它为平台上的所有用户，开创了一种大众分类法。从而更有效的在用户之间对 web 链接进行分类和共享。

del.icio.us 所用的是一种创新的方法。 用户可以用 URL http://del.icio.us/tag/[标签名]/ 的形式搜索标签列表，或者公开的 web 书签。 例如，如果我要搜索关于 airplane 的书签，则我可以输入 http://del.icio.us/tag/airplane，这样我就可以获得所有标签是“airplane”的书签列表。非常简单。

再来说说它的编程接口， 那更是一种顺畅的体验。 如果你想要“airplane”标签的 html 页，则输入http://del.icio.us/tag/airplane。 如果要 RSS的标签，则输入http://del.icio.us/rss/tag/airplane。 如果要 XML的，则输入http://del.icio.us/api/tag/airplane。 当然，在最新版本中，这些 API可能已经变化了。

del.icio.us 是第一个给出了铁证，证明了使用简单易读的 URL，可以同时提供 HTML 内容，以及机器可读的 RSS 和 XML。这种分享书签的技术，为未来的 API 开辟了道路，从此以后，API 对于开发者和非开发者，都一样容易理解。 任何轻度的技术用户，都能够轻松的解析 XML 或 RSS。并能够开发或者反向编译围绕del.icio.us内容的widget和app。

自从流行后，del.icio.us已被出售了两次。一次在2005年出售给 Yahoo!，一次是2011年出售给 AVOS System。 但是，del.icio.us依然是 API 大潮在社交时代中的支柱平台。经由它，确立了 API 分享在 API 经济中的关键地位。还经由它，“简单”成为 API 设计的根本原则。

• Flickr

2004 年 12 月，Flickr 发布。这是一款非常流行的图片分享应用。 六个月后，Flickr 发布了它们的 API服务。再过六个月，Flickr 被 Yahoo 并购。

Flickr 刚开始，是一个在线游戏，但它快速的演变成了社交照片分享，而且轰动一时。

Flickr 发布的 RESTful 风格的 API，迅速吸引了早期的博客和社交媒体。用户可以利用这种 API

方便的将 Flickr 照片嵌入到博客和社交网络中，由此 Flickr 成为了图片平台中的老大。

Flickr 的联合创始人 Caterina Fake 创造的概念 BizDev 2.0 （业务拓展 2.0），就是来源于 Flickr API的灵感。 Flickr 没有办法满足服务需求的暴涨，于是建立 API以提供自助服务来拓展业务，想起来也是理所当然之举了。

这种使用 API 的核心理念，其意义已超越创造它的 Flickr 公司本身，乃至并购者 Yahoo。 API 业务模式的精髓之一就是利用 API 进行业务扩展。在这种模式中，把 API 已经不仅仅是一个技术概念了。

API 已经成了企业经营生意的利器。面对合作伙伴也好，公众消费者也好，各种业务中都可以使用 API。但 API 的发展壮大，还有更远的路途要走。

• Facebook

2006年8月15日， Facebook 发布其开发平台和 API时，人们已经等待良久。 Facebook 开发平台的1.0 版本提供对 Facebook 好友、照片、活动和个人信息的访问。

API 使用 REST， 信息以 XML 格式提供。这也是当时社交 API 最通用的做法。

几乎是一瞬间，开发者们就用这些新的开发工具，创建了各种社交应用、游戏和糅合（Mashup）应用。

正是 Facebook 开发平台，让Facebook彻底战胜了它的老对手 MySpace。 也正是Facebook开发平台，让Facebook凭借 Farmville 等游戏，一跃成为社交游戏平台中的霸主。

虽然在开发者圈子中，对Facebook API和平台的不稳定性，颇多诟病。 但随着越来越多的应用和合作伙伴的加入，越来越多的新功能和新体验也层出不穷， Facebook API 和平台，无疑是关键的驱动力。

• Twitter

2006 年 9 月 20 日， Twitter 将 Twitter API 推向世界。

有点类似 eBay API, Twitter 推出 API 也是无奈之举。 太多的网站攻击和太多的非法 API，让Twitter不胜其烦。

Twitter 公开的 API，以 REST 风格的接口提供 JSON 和 XML格式的数据。

刚开始，Twitter 使用 Basic Auth 来做 API 认证。 四年后，Twitter 转而使用 OAuth，强制要求所有的 API 请求都要通过认证。这也就是 Twitter OAuth Apocalypse 诞生的故事。当然，Twitter OAuth Apocalypse 在今天口碑不佳。

短短四年里，Twitter API 成了无数桌面客户端、移动应用、web 应用和业务系统的中心。 甚至 Twitter 自己，也在其开发的 iPhone, iPad, android 应用中使用这些 API。

Twitter 是最重要的 API 平台之一。 同时，它极好的说明，只做好一件事的极简平台，完全可以大获成功。只要通过 API 形成开放访问，那么开放的 API 生态会带来无限可能。

Twitter 也是一个重要的反面教材。提醒人们注意 API 生态环境的负面作用。 在 API 生态环境的发展过程中，必须慎重考虑各种政治因素。

商业和营销

API 源自电商，走进社交，很明显这个行业需要一些标准化。 方法就是引进一些常规的商业规范。这个行业需要对 API 部署的方法进行标准化，也需要提供营销手段来对 API 和常规的商业规范进行宣传。

为 API 领域建设常规的商业和营销规范，需要在普通大众中进行传播，并对 API、还有其中的公司及行业广为宣传。 自2005年至今，我们知道有两家独立的 API 开拓者，正在进行 API 行业定义。

• ProgrammableWeb

在研究 API 的历史中，关注点极易局限于 API 本身。 而忽略了 web API 整个历史上最重要的那个孤独身影 －ProgrammableWeb。

2005 年 7 月， John Musser 创立了 ProgrammableWeb。 在他最早的“关于我们”页面上，他是这么说的：

ProgrammableWeb 是一个基于“网络即平台”理念的推荐站点和博客。 我们针对使用 Web 2.0 API 来开发应用的人，提供各种新闻、信息及资源。

之所以创建这个网站，是因为我自己想用，却无法找到类似的站点： 为 web 平台开发提供一个技术上的起点。虽然无法确证，但我创建的上一个推荐站点，在 Google 的该类主题中，排名几乎是最高的。而这个站点，会有来自社区的各种协助和努力，相信它会更加成功。

希望于您有助。

John Musser – 西雅图， 2005年8月

John 在更早的博客中，也言及创建 ProgrammableWeb 的初衷： 为什么？ 因为从 Web 页面到 Web 平台，是一个巨大的机会。

Web API 是个巨大机会！ 无论是对社交网络，还是政府、健康产业，或者教育行业，有一个可编程的平台以交换数据和资源，都将在以后的商业和社会运作中，发挥重要作用。

John 的决心下的很早。他要对比两种技术潮流。一种是开放的 RESTful 风格的 API。另一种是并行发展的SOA 和 Web 服务。他关注于宣传开放的 API。而这一切发生时，硅谷对开放 API 还并不了解。

几年之后，web API 技术在硅谷广为接受，这也要归功于 ProgrammableWeb 的宣传。

时至今日， API 已经成为一个主流技术和应用模式。我们依然要感谢 ProgrammableWeb。 John，Adam 还有其它作者在 ProgrammableWeb 上所做的宣传，对于定义 API 行业至关重要。从此，我们开始创造、改进并大步向前。

如果不是这些从技术、商业和政治角度对 API 展开的讨论，这些虚拟的接口，可能还无法在我们现实生活的世界中找到一席之地。

• Mashery

2006 年 12 月， Mashery，第一个 API 服务提供商，“低调” 的出现。它为那些想要提供公开和私有 API 的公司，提供文档支持、社区管理和访问控制。

2006年的这个时刻，我们正见证着 API 从社交时代，进入云计算时代。标志事件就是 Amazon Web Service 的诞生。 再无疑问， web API 的世界成为现实，对于提供 API 管理服务的公司来说，这是巨大的市场机会。

虽然有很多工具可以部署 API，但仍然还没有管理 API 部署的标准方法。 Mashery 是第一个为 API 提供商引入标准服务的。从而为 API 行业未来的发展，奠定了一个台阶。

到 API 行业成熟，还需6年的光阴，在这个历程中 Mashery 贡献巨大。 今天我们熟知的这个领域，是由早期的先驱，包括 SalesForce 和 Amazon， 社交先驱 Flickr 和 Delicous 所定义。 而 Mashery 则定义了今天的商业 API。

2013 年， Mashery 被 Intel 收购。 再次证明 API 行业已然成熟。

地图

一个早期的 API 先驱，敏锐的看到了一个需求。那就是为 web 开发者提供简单的，基于 javascript 的地图，帮助实现在线导航、寻找内容、甚至在现实世界中导航。

web 开发者马上看到了可嵌入地图的巨大潜力。 他们想办法攻破了各种地图资源，然后创造了各种用户喜爱的 web 应用，为用户解决日常的各种本地问题。

在为开发者提供地图工具和服务的这些 API，为早期的移动开发者提供了指引。 而移动 API 时代，也随之而来。

• Google 地图

2006 年 6 月 29 日，google 发布 google 地图 API。 开发者可以使用 JavaScript 在自己的网站中嵌入 google 地图。

google API 的发布仅仅晚于 google 地图应用 6个月。 也是为了应对层出不穷的那些非法接入google地图的流氓应用。google 地图太受欢迎，开发者们破解了 JavaScript 接口，开发了类似housingmaps.com和chicagocime.org之类的应用。 破解 google 地图的需求是如此强烈，O’Reilly上甚至出了“地图破解” 和“google 破解”这样的书。

google 地图 API 引发了糅和应用（mashup）热潮。位置信息数据被广泛应用。今天，总计约有2000多种这样的糅和应用（mashup）。

API 展现了地理位置数据和地图API的无尽价值。 也展现了用户们的力量，这种力量在极大的左右着应用和API的发展方向。Lars Rasmussen，是 google 地图最早的开发者。 他承认，在开发者社区中观察开发者如何实时破解应用，让他学习到很多知识。而且实际上，他们也把这些知识应用到了今天的 API 中。

没有几家公司，拥有google那样丰富的资源，能够完成世界地图这样的项目，并发布可复用、基于 API 的资源。在 API 的世界里，google 在各方面都居功至伟。 但 google 地图在 API 的历史中，还是不可比拟。

云 计 算

就在 API 在互联网上闹哄哄的时候，Amazon 看到了 RESTful 理论在商业上的潜力。它敏锐的察觉到了API世界里一块无人触及的处女地。 Amazon 创造了使用 API的新方式，这种方式带了了远超电商的意义。 Amazon 重新发明了计算。

Amazon 变革了我们对构建 web 应用的认识。 通过 API 的运行，提供了让 API 运行所需的最关键因素。我们今天所谓的云计算，改变了一切。 移动、平板、传感器，以及其它 API 驱动的领域，才具有了发展的可能性。

云计算，是 API 行业错失的关键要素。

• Amazon S3

2006 年 3 月， Amazon 发布了新的 web 服务。完全不同于 Amazon 的买书和电商业务。这是 Amazon的新征程： 存储的 web 服务，成为 Amazon S3。

Amazon S3 提供了一个简单的接口，用来存储和检索数据。用户通过 web 上，可以在任何时间、任意地点处理任意数量的数据。 这些开发者可以用来数据存储的基础设施，和 Amazon 运行自己网站所使用的一样。具备同样的高扩展性、高可靠性、高效性能，并且价格低廉。

Amazon S3 或者“简单存储服务”最初就是一个 API。 没有 web 接口或者移动 app。 仅仅是一个 RESTful 风格的 API，可以对文件或者对象执行 PUT 和 GET 请求。

开发者使用 S3 API，每月每个G的容量，要付的价格是 0.15 美元。

通过这种新 API和新收费模式，Amazon 创造了一个新的计算类型，现在我们称之为云计算。

这也意味着，API 不仅仅为了数据或者简单功能，还可以用来提供运算基础设施。

• Amazon EC2

2006年8月，就在 Amazon S3 发布之后不久，Amazon 又发布了一个新的云计算服务，称之为 Amazon EC2，全名是“弹性计算云”。

Amazon EC2 在云端提供可随意配置大小的计算能力。开发者可以在 Amazon 数据中心里，启动不同大小的虚拟服务器。

和前辈Amazon S3一样，Amazon EC2 也只是一个 RESTful 风格的 API。在接下来的三年里，Amazon 一直没有发布 web 接口。

开发者使用 Amazon EC2 API，可以启动小型、大型和超大型服务器。按照服务器运行的小时数收费。

Amazon S3 和 Amazon EC2 一道，为平台提供了新一代的计算模式。而 API，是这种模式的核心。

移动的世界

随着 iPhone 和 Andorid 智能机的兴起， API 从服务电商、社交和云计算，开始走向为移动手机提供资源。而我们口袋里的这个智能机，很快就要主宰我们的地球。

API 让重要的资源实现了模块化、可移植和分布式。 无疑，在开发移动和其它各种形状和各种尺寸平板应用中， API是最佳通道了。

为数不多的一些 API 平台，开始定义这部分领域。他们所开发的应用，让他们赢得了开发者和用户的全心热爱。

• Foursquare

2009 年 3 月， SXSW 嘉年华在德州的奥斯汀举行，就在那时，Foursquare 发布。

Foursquare 是一款移动平台，基于位置信息，让人们更热爱去探索城市。通过使用智能机 app 或者短信签到，用户可以与朋友分享位置信息，同时获得积分和虚拟勋章。

2009 年 12 月，Foursquare 完成了一轮天使融资，投资者包括 Union Square Ventures和

O’Reilly AlphaTech Ventures。随后，Foursquare 发布了他们的 API。

在 API 发布时，Foursquare 已经有了一些来自合作伙伴的应用。包括一个 Andorid 应用和来自 Layar的增强现实应用。

Foursquare 面对的竞争很多。Gowalla，起步更早。Facebook 和 Google 更大。但 Foursquare 依然是最主流的位置分享和签到移动平台。

• Instagram

2010 年 10 月 6 日， Instagram 发布了照片分享应用。

那个时候，它仅有一百万用户。而三个月后，用户数将远超此时。

Kevin Systrom， Instagram 的创始人，他专注于提供强大但易用的 iPhone app。目标是为人们解决使用手机拍照中普遍面临的问题： 照片质量、和无法分享。

但很快，许多用户开始抱怨，Instagram 缺少后台网站或者 API。 Instagram 的焦点依然停留在核心iPhone应用。

12 月份，一个叫 Mislav Marohni 的开发者，反向编译了Instagram app，并自行开发了非法 InstagramAPI。

1月份，Instagram 切断了非法 API，并宣布正在开发自己的 API。

2011 年 2 月，Instagram 发布了图片平台的官方 API。

几天内，围绕着这个 API，就出现了许多照片应用，照片分享网站，以及糅和应用(mashup)。

Instagram 成为了一个病毒式传播的 iPhone app。但马上它就需要一个 API 来充分发挥潜力。 在 API 的移动时代，它作为一代霸主的地位无法撼动。

• Twilio

2007 年， 一个新的 “API即产品”（ API-as-a-product）平台诞生，名字是 Twilio。Twilio 提供语音 API，开发者可以用以开发打电话和接收电话的云应用。 在过去的3年里，Twilio 还另外发布了短消息和 SMS 验证码 API。这样 Twilio 就成了开发者工具箱里最重要的电话通讯资源。

在对开发者进行传播时，Twilio 是一个经典平台。 Twilio 清楚的定义了一个健康的 API 平台，需要那些技术和业务的模块来构筑。 Twilio 也给 API 的宣传者在各种活动和编程马拉松中，设定了一个标杆。 Twilio 一直在努力去推广、支持并投资开发者生态。

与 Foursquare 和 Instagram 一样， Twilio 也开始定义移动开发，帮助推动 API 进入主流应用。谈到 API，Twitter 有时会成为反面教材。但 Twilio 则说明，只要做对了， API 完全可以推动生态系统运行。

2011 年时，通过 HTTP 提供 API 的标杆已经建立。建设者包括那些早期的先驱，例如 SalesForce 和 Amazon。 但通过在移动时代发起的革命， Twilio 再次证明了 API 业务是多么成熟。当然，基于 API 的移动开发，依然扎根于电商、社交和云计算所铺设的基座上。

了解历史

了解历史，为的指引未来。 我们把 web API 的过去，称之为历史，也许并不十分恰当。毕竟那跨度只有短短的十几年。 但 API 的先行者们积累了太多的经验，需要学习和研究，我们不能忽视。 如果技术专家们方法得当，API 也许在电商时代就已大为成功了。 但伴随着 Amazon，Twitter， Twilio 这些公司的伟大创新，我们现在深刻理解了 API 业务需要几个关键的成分： 电商、社交、云计算和移动。

当然，说到底，还是需要赢利。 不过，API 需要可扩展，也需要提供对用户有用的工具、服务和资源，否则一切都将落空。当我们坚定的站在 API 发展的移动时代，看到这个时代的变革围绕设备和物联网而产生，我们必须了解过去的历史，也必须了解我们如何发展到现在，只有这样，我们才能对未来的发展做出正确的决策。

Web API 的意义在于，通过万维网提供有价值的、有意义的、可扩展的、分布式的资源。 当硅谷在不断开发下一代技术解决方案时，我们一定不能忘记过去。