人们是令人惊讶且不可预测的。在计算机行业，几乎每次采访流行软件包的设计者时都会听到这句话。例如，Perl 最初是为网络编程和文本处理而设计的。这使其成为 Web 编程的显而易见的选择，但 Larry Wall 在首次编写该语言时，肯定不知道或没有预料到这一点，那时 Web 尚未发明。

软件包的用户几乎总是会突破其限制。这就是为什么一些最成功和最流行的程序是那些鼓励用户超越作者想象力的程序。在软件行业的早期，这种附加组件和插件并不存在，这意味着获得新功能的唯一方法是游说作者，然后希望下一个版本包含所需的功能。在开源软件的世界中，理论上任何人都可以添加新功能，但由于核心开发人员数量通常很少，以及有时爆发的著名的激烈辩论，添加新功能可能需要出奇地长的时间。（虽然始终可以 fork 一个项目，但这具有社会和技术上的缺点，这些缺点通常超过了好处。）

一些程序具有鼓励附加组件的悠久传统。GNU Emacs 最出名的是文本编辑器，但它带有一个完整版本的 Lisp 编程语言。您几乎可以在 Emacs 中创建任何您想要的东西，人们也确实这样做了，包括邮件阅读程序、Web 浏览器和极其复杂的日历/日记。Photoshop 在图形设计师中流行起来，不仅是因为其强大的图像编辑功能，还因为为该平台开发（和销售）的大量插件。Microsoft Office，尽管它可能受到许多 Linux 和开源倡导者的诟病，但因其内置的编程语言 (VBA) 以及其内置功能而变得流行。而且，当然，如果不是因为我添加到软件中的六个插件，Firefox 浏览器对我来说就不会那么有用。

因此，用户将软件推向极限，并且软件发布商通过使其程序可扩展来使其产品更有用。这在基于 Web 的软件时代如何体现？这对我们作为 Web 开发人员意味着什么？

答案是日益普及的应用程序编程接口，或 API。如果您希望您的网站被认真视为平台，而不仅仅是一个应用程序，您需要提供一个 API，让用户可以创建、修改和扩展您的应用程序。API 正在成为基于 Web 的应用程序越来越标准的一部分，但尽管每个人都在使用术语 API，但对于不同的人来说，该首字母缩略词意味着不同的事物。

从下个月开始，我将研究 Facebook 等网站提供的最新一批 API。但本月，我想退后一步，考虑软件发布商提供的不同类型的 API。如果您打算扩展、使用和使用这些 API，这将非常有用。Web 开发越来越成为将其他网站的现有功能联系在一起的问题，而理解这些 API 可能非常有用。

对于 Web 开发人员来说，理解 API 的本质也很重要。如果您想创建下一个 Facebook 或 Google，您需要的不仅仅是一个成功的产品。您需要围绕您的核心产品建立一个由开发人员和第三方软件组成的生态系统。做到这一点的最佳方法之一是创建和推广 API，让人们将您的应用程序用作平台，而不是独立程序。通过环顾四周并了解其他人所做的事情，我们可以更好地了解可能性以及我们如何使用它们。

最初，当 Tim Berners-Lee 发明 Web 时，他将其想象为读写介质。但对于在第一个十年中使用 Web 的大多数人来说，它是一个只读介质。您可以使用浏览器查看网站，使用浏览器填写表单，仅此而已。没有用于读取网站的 API；如果您想以编程方式读取网站的内容——例如，为了创建所有 Web 内容的可搜索索引——您需要创建自己的“蜘蛛”程序，并教会它分解 HTML。

这种情况在 1990 年代后期发生了变化，当时许多开发人员（最突出但不完全包括 Dave Winer）创建了 RSS，代表真正简单的联合或 RDF 站点摘要。在任何一种情况下，其想法都是创建站点内容的机器可读、频繁更新的摘要。通过检查站点的 RSS feed，您可以了解是否有任何更新。更重要的是，RSS feed 以标准方式格式化，带有标准标签，这使得程序可以相当容易地轮询 feed 并仅提取他们想要的信息。

不幸的是，术语 RSS 既成为联合的通用术语，又成为几种不兼容（但相似）的联合格式的名称。另一组开发人员创建了 Atom 协议，许多人认为该协议优于所有各种 RSS 格式。

RSS 和 Atom 今天仍然很流行。这些联合 feed 最常见的用途是用于博客和新闻更新，允许用户跟踪哪些站点已更新其内容。但是，RSS 和 Atom 也可以用于其他方面，提供来自网站的各种类型数据的简单、可靠和机器可读版本。如果您希望广播定期更新的数据，RSS 和 Atom 可能是很好的起点。

例如，著名的开发公司 37Signals 提供了其 Highrise 联系人管理系统中最近活动的 Atom feed。查看您自己的 feed 可能很有帮助，但将多个人的 feed 聚合到一个查看器中会更有帮助，例如，让经理了解员工每天完成的工作（以及数量）。

网站可以提供定期更新、机器可解析的内容版本的想法激起了许多开发人员对更多内容的需求。许多开发人员想要一种添加和修改数据以及检索数据的方法。

这以几种不同的形式出现，所有这些形式至今仍在使用。第一个是 XML-RPC，一种简单的 RPC 协议，它使用 HTTP 在远程服务器上发送 XML 编码的函数调用。服务器将 XML-RPC 请求转换为本地函数调用，并在 XML 编码的响应中发送该调用的结果（或错误消息）。好消息是（并且现在仍然是）XML-RPC 简单易懂且易于使用，有许多不同语言的实现，并且它们通常兼容且可互操作。

与此同时，XML-RPC 无法处理人们想要使用的一些更复杂的数据类型。此外，它没有获得官方认可或完整的标准，这对于它进入企业领域是必要的。因此，一些最初的 XML-RPC 开发人员创建了 SOAP（最初称为简单对象访问协议，但现在是一个不扩展的首字母缩略词）。SOAP 比 XML-RPC 更复杂和完整，但它在兼容性、实现和复杂性方面存在许多问题。今天，有许多语言的 SOAP 实现，尽管存在一些兼容性问题，但它仍在以各种方式使用。

但是，在 XML-RPC 和 SOAP 被吹捧为新型交互式、机器可解析 Web 的基础的同时，Roy Fielding 出现了，他将当前的状态描述为不必要的复杂。他建议，与其在请求和响应中都使用 XML，不如使用具象状态传输 (REST)。换句话说，URL 应包含描述请求所需的一切，而无需任何额外的 XML 标记或有效负载。当然，响应可以是 XML 或任何其他格式。

发布的 Web 服务、通过 HTTP 和 URL 调用并在 XML 和其他格式中传输数据的过程的想法很快变得普遍。创建和使用 Web 服务成为最重要的事情，每家公司都在谈论如何利用此类 Web 服务。提出了许多用于描述和查找 Web 服务的标准；就我所知，这些标准仍然存在，但对于普通程序员来说，它们不存在，我不确定它们是否以及何时会存在。

鉴于有两种只读协议和三种读写协议，人们迟早会开始创建利用这些协议的应用程序。亚马逊是最早这样做的公司之一，它以一组 Web 服务形式开放了其目录，现在称为亚马逊电子商务服务或 ECS。亚马逊通过 ECS 提供其整个目录，并允许程序员在 SOAP 和 REST 之间进行选择。多年来，ECS 已发展成为一个日益复杂和功能强大的系统，可以检索亚马逊目录和定价信息的特定切片。

但是，从亚马逊检索信息只是故事的一半：亚马逊还允许通过 ECS 管理购物车，甚至提供一些用于管理第三方产品的销售的工具。亚马逊对 ECS 做出了巨大的承诺，并且围绕该工具现在存在一个庞大的开发人员和第三方软件供应商社区。通过将亚马逊变成软件开发的平台，而不是简单的在线商店，亚马逊同时让一群人依赖 ECS，并为创建原本永远不会构建的软件应用程序创造了机会。

eBay、Google 和 Yahoo!（以及其他公司）也通过 Web 服务提供了许多 API，开发人员可以使用各种协议来使用和访问这些 API。我读到了一些报告，我无法证实但愿意相信，声称提交给 eBay 服务器的大部分请求都是通过其 Web 服务进行的。鉴于大多数 eBay 用户的技术水平不足以创建自己的 HTTP 客户端，我们可以假设有很多软件开发商店将 eBay 视为分发平台，就像其他人可能将 Windows 或 Linux 视为他们的平台一样。

Google 还将其许多应用程序公开给读写 API。Google 没有使用现有协议之一，而是对请求和响应都使用 Atom 版本，以及一种称为 GData 的数据格式。Google 的许多应用程序都有读写 API，包括日历、Blogger 和电子表格程序。程序员不再受 Google 为其电子表格数据提供的界面的限制；他们可以创建自己的程序，使用电子表格进行存储和检索。（一个稍微牵强的例子是创建一个分布式数据库服务器，该服务器依赖 Google 的电子表格进行锁定和版本控制。）

尽管此类新 API 不断推出，但趋势似乎很明显。使数据易于用户以各种格式轻松获取和下载。并且，使他们能够使用您的网站或（或者）命令行或他们自己的自制应用程序与您的基于 Web 的应用程序进行交互。

Facebook 是由马克·扎克伯格创立的社交网站，已成为 Web 上极其流行的应用程序。Facebook 用户可以与朋友联系，加入志同道合的个人群体，并向他人发送消息。早在 2007 年，Facebook 就因创建了一个开发者 API 而在开发者和用户中流行起来，该 API 远远超出了我上面描述的 API。简而言之，Facebook 邀请开发者创建和部署与完整 Facebook 体验无缝集成的新应用程序。

Facebook 并不是唯一允许您将自己的代码合并到站点中的站点。但是，这种集成的风格和方法在 Facebook 上比我在其他地方看到的更深入。在 Facebook 模式中，您的 Web 应用程序仍然驻留在您的服务器上，但其输出显示在用户的 Facebook 页面内，与其他 Facebook 应用程序并排显示。这绝对是新的和令人兴奋的；我想不出任何其他网站可以让独立开发者分发集成到网站中的代码。您可以随意使用您喜欢的任何语言和平台，以某种方式与 Facebook 通信，这一事实标志着一种新型 API 的开始，在这种 API 中，用户可以影响所有用户（而不仅仅是特定用户）看到的 Web 服务。我能想到的另一个属于这一阵营的网站是 Ning，马克·安德森的构建您自己的社交网络网站。

此外，Facebook 从亚马逊和 eBay 那里吸取了教训，告诉开发者他们可以尽情发挥，将 Facebook 网络用于商业和非营利目的。例如，Google 长期以来一直允许访问其地图，但仅限于公开访问的网站和原因。Facebook 的 API 是否将继续免费并向所有人开放，仍有待观察。

如此复杂的东西无法使用我上面提到的任何一种协议。相反，Facebook 使用协议和技术的组合与您的 Web 应用程序通信，使您的程序可以与其他 Facebook 应用程序一起显示其输出。此外，Facebook 使您的应用程序可以获取用户 Facebook 数据的某些部分，因此即使您的应用程序无权访问后端 Facebook 数据库，它仍然可以了解（并显示）有关用户朋友的信息。您的应用程序甚至可以向用户的朋友发送消息和通知，尽管 Facebook 已经发现这可能会导致垃圾邮件，因此仍有待观察这方面究竟会发生什么。

网站过去只不过是一种以 HTML 编码发布和阅读基本信息的电子方法。但是，网站演变为应用程序，从而催生了第一代 API，这些 API 使读取和写入数据成为可能。Facebook 是新一代网站中的第一个，它将自己视为平台而不是应用程序。

而且，尽管亚马逊、Google 和 eBay 已经证明了以平台为中心的观点的重​​要性和潜力，但 Facebook 正在率先整合第三方应用程序。诚然，迄今为止创建的大多数 Facebook 应用程序都很简单或微不足道。但是，我们可以预期，随着时间的推移，这些应用程序将变得越来越复杂和有用。Facebook 愿意向第三方开发者开放对每个人都有好处——除了竞争对手网站，例如 MySpace 和 LinkedIn，它们似乎仍然将自己视为独立网站，而不是新应用程序的平台。

本月，我解释了为什么我发现 Facebook 的 API 是新的且令人兴奋的。下个月，我们将研究如何创建您自己的 Facebook 应用程序。即使您对为 Facebook 创建应用程序不感兴趣，您也有义务了解最新一代 Web 应用程序如何允许自己被修改，而不仅仅是被查询。