客户端请求	服务器响应
GET /hello.txt	Hello, world!

就这么简单。 你连接到服务器，把文档路径给它，然后服务器就把文档内容返回给你。 HTTP 0.9 差不多就只支持这么些了，看似只是毫无特色地照搬比它复杂一点的文件传输协议（FTP）。 令人意外的是，答案基本就是这样。 我们可以半开玩笑地讲，HTTP是特别适合分布式Internet应用的，因为它没有值得一提的特性。 你讲你要什么，它就给你什么。 跟功夫片里的手法同出一辙，[2] HTTP的缺点转化成了优势，它的简单性转化成了强大能力。

HTTP 0.9是特地设计为那么简单的。从HTTP 0.9中我们可以看到可寻址性（addressability）和无状态性（statelessness） ——正是这两条基本设计原则，令HTTP较其同类更加优秀，并得以延伸到今天如此巨大的规模。 在HTTP 0.9所缺少的特性中，大部分已被证实为是多余的、甚至是有副作用的（其实，添加那些特性，将有损于Web），而其余的许多特性已在HTTP 1.0和1.1版中实现了。 Web赖以成功的另两项重要技术是：URL和HTML（以及后来的XML）——它们在许多重要方面也是简单的。 显然，这些“简单的”技术在功能上已足够强大，它们支持Web及Web上的应用。 在本书中，我们进一步提出：万维网（World Wide Web）是一个简单而灵活的分布式编程环境。 而且我们认为其原因是： 为人类使用而设计的human web，跟为软件程序调用而设计的“programmable web”，没有本质区别。 我们认为， 如果Web能很好地为人类所用，那么它也同样能很好地为程序所用。 我们只需要多作一些考虑即可。 计算机程序擅长于构建和解析复杂的数据结构，但是在理解文档方面，它们无法做到像人类一样灵活。

复杂的大Web服务

用作构建Web服务的协议与标准有很多，它们大多是构筑在HTTP之上的。 这些标准被统称为WS-*标准栈。 它们包括WS-Notification、WS-Security、WSDL及SOAP等。 在本书中，我们用“大Web服务（Big Web Services）”来称呼这些技术，以较为礼貌地表达我们对它的鄙视。 本书不将对这些标准作详细介绍。 我们觉得，实现Web服务并不一定非得用大Web服务（Big Web Services），相反，用Web就足够了。 我们相信，Web基础技术足以成为默认的分布式服务平台。 对于某些WS-*标准（例如SOAP），你可以做到使用它们、而不违反REST及面向资源的架构（Resource-Oriented Architecture）。 但实际上，它们被用于实现基于HTTP的远程过程调用（Remote Procedure Call，RPC）。 有时，采用RPC式架构是合适的；有时，有比Web的优点更为重要的需求得考虑。这没关系。 不必要的复杂性是我们所不期望的。 有些场合，采用普通老式的HTTP（plain old HTTP）就足以应付了，但程序员或公司却经常采用大Web服务（Big Web Services）。 这样做的效果是，HTTP成为一种用于传输庞大XML负载（payload）的协议，而“真正的”描述信息在XML里。 最终的服务变得太过复杂、难于调试，而且要求客户端必须与服务端具备同样的配置环境。

大Web服务（Big Web Services）确实有个优点：现今的开发工具使你只需点一下鼠标、就可以根据你的代码生成Web服务（尤其是Java或C#开发）。 在用这些工具来生成符合WS-*标准栈的RPC式Web服务时，REST式Web服务的简单性这一优点对你来说也许已经不重要了， 因为这些工具已经隐藏了所有的复杂性，不用让你操心。 毕竟带宽和CPU都便宜。

假如是在同质（homogeneous）环境中、且服务都在同一个防火墙之后的话，那么这种做法是可行的。 如果你的机构有足够的政治影响力，你们可以要求防火墙外的其它机构也采用跟你们同样的方式。 但是，假如你期望你的服务逐渐发展到Internet规模，你就必须能够应付你没有事先考虑到的客户端，比如采用你从没想到的自定义软件栈（software stacks）来访问你的服务。 你的用户会试图把你的服务与其他你没听说过的服务集成起来。 貌似很难？ 这在Web上已经司空见惯了。

抽象（abstraction）也不是完美的。 每增加一个层次，就多一些故障点（failure point）、互操作难题和可伸缩性问题。 现代化开发工具能够隐藏复杂性，但它们无法为引入复杂性解释原因——它们就知道不断地增加层次。 要令服务融入Web，就要在适应性（adaptability）、可伸缩性（scalability）及可维护性（maintainability）方面多加注意。 而简单性（simplicity）——HTTP 0.9被忽视的优点——则是这三者的先决条件。 系统越是复杂，出错时纠正起来就越是困难。

如果你提供REST式Web服务，你可以把复杂性投入于“实现更多特性、实现不同服务之间的交互”上。 成功地提供服务，意味着不光是把服务构筑在Web“之上”，而且应该令服务融入Web： 设计服务时，应遵循跟“良好的网站设计所采用的”一样的原则。 跟基本的Web协议靠得越拢，这就越容易实现。

关于REST

REST虽然简单，但它是良好定义的（well-defined）；而且，不能因为“Web服务和网站是一样的东西”，就以简单性作为“把Web服务实现成功能贫乏的网站”的借口。 可惜到目前为止，主要的REST参考文献只有Roy Fielding 2000年的博士论文第五章——就博士论文来说，那是很好的资料；不过对于大部分现实问题，它并没有给出回答。[4] 这是因为，那篇博士论文不是把REST作为一种架构来诠释，而是把REST当作一种评判架构的方法来介绍的。“REST式（RESTful）”这个术语就像“面向对象（object-oriented）”这个术语一样。 一门语言、一种框架或一个应用也许是采用面向对象的方法设计的，但这并不一定确保其架构是面向对象的架构。

即使采用像C++或Ruby这样面向对象语言，也有可能写出不是真正面向对象的程序出来。 按照REST的标准，HTTP在理论上是很好的。 （这是理所当然的，因为Fielding参与了HTTP标准的编写，而且他在博士论文里描述了Web的架构。） 不过，在现实中，网站、Web应用及Web服务等经常与REST原则相违背。 那么，在对具体的Web服务进行设计时，你怎样才能确信自己正确运用了REST原则呢？

大部分关于REST的信息来源都是非正式的： 邮件列表（mailing list）、Wiki、博客等（我在附录A中给出了一些很好的链接）。 直至如今，REST的最佳实践（best practices）还只是一些坊间传言（folklore）。 所需要的，是一个以REST元架构（meta-architecture）为基础的具体架构（architecture）： 一套为设计“体现了Web的潜力”的服务而制定的基本准则——我们将在第四章介绍这样一种架构，即面向资源的架构（Resource-Oriented Architecture，简称ROA）。 它并不是唯一的高层（high-level）REST式架构，但是我们认为，用它来设计“易于为客户端所用”的Web服务是很好的。

我们通过制定这个面向资源的架构（ROA），把来自坊间传言（folklore）的经验提炼为Web服务设计的最佳实践（best practices）。 它们仅作为一个建议的基线（suggested baseline）。 如果你曾经力图领会REST，我们希望我们的架构能够令你自信地认为你所做的是“真正的”REST。 我们也希望，我们的面向资源的架构（ROA）能够帮助整个社区加快提出并系统化最佳实践。 我们希望让程序员可以轻易地构建优雅的、符合设计用途的、融入Web的（而不是仅仅构筑在Web之上的）分布式Web应用。 但我们知道，你光掌握这些技术还是不够的。 我们两人都曾有过这样的经历：我们所工作的机构，在主要的架构决策上没有按照我们的意思去做。 如果你没机会采用REST式架构，你是无法在REST式架构方面取得成功的。 因为，除了技术知识以外，我们还必须教你怎样用言辞去推荐REST式解决方案。 我们已经把面向资源的架构（ROA）定位为一种替代RPC式架构（即如今的SOAP+WSDL服务所采用的）的简单方案。 RPC式架构通过一个复杂的、编程语言式的接口，来暴露其内部算法（algorithms）——这种接口，每个服务都各不相同。 而ROA则通过一个简单的、文档处理接口，来暴露其内部数据（data）——这种接口是统一的。 我们将在第十章对这两种架构加以比较，并教你如何来推荐采用ROA。

统一两种Web

程序员把网站作为Web服务来用，这已经有好多年了——当然，是非正式地。[3] 要让计算机理解供人类阅读的网页，是比较困难的，但这并没有阻止程序高手们用自动化客户端来抓取网页、然后用屏幕抓取程序来提取有关信息。 随着时间的推进，出现了RSS、XML-RPC和SOAP这些对程序员友好的技术——它们用于按正式认可的方式来暴露网站功能。 这些技术形成了一种programmable web，它是对human web的扩展，它为软件程序提供了方便。

我们写这本书的最终目的，是统一programmable web与human web。 我们设想的是单个互联的网络： 一个“在一组服务器上运行、采用一套协议、并遵从一组设计原则”的万维网（World Wide Web）。 那是一个既可被人、也可被计算机程序使用的网络。

若不是蒙惠于分配不当的国防资金、创新的工程项目、“差点则更好”（worse-is-better）的工程实践、大科学、天真的自由理想主义、古怪的自由主义政治、技术迷信、以及那些认为自己找到了发财之路的程序员和投资者的汗水与资本，因特网（Internet ）和万维网（World Wide Web）也许不一定会诞生。

Web作为一个简单的、开放的（至少现阶段）和基本统一的网络应用平台， 它容纳了大量的人类知识，并为人类所努力钻研的许多领域提供支持。 我们认为，现在应该开始认真考虑将网站设计原则应用于服务设计了，以便自动化客户端可以访问那些信息和算法。 假如你同意的话，本书将教你怎么做。

本书的内容

在本书中，我们主要关注一些实际问题： 如何设计与实现REST式Web服务（RESTful Web Services）以及调用它们的客户端。 其次我们还关注于理论方面： 什么是REST式架构风格？为什么Web服务应该尽量符合REST风格？ 我们的讨论不会涵盖方方面面，但是我们力图切入如今的重点话题。因为这是同类书中的第一本，我们会不断反复这一关键问题——即如何设计一个REST式服务。

前三章，将从客户端的角度来介绍Web服务，并告诉你REST式服务有什么特别不同。

第一章 Programmable Web及其分类
我们在这一章对Web服务作总体性介绍。 Web服务是运行于Web上、请求外部服务器提供数据或运行算法的程序。 我们将展示三种常见的Web服务架构： REST式架构、RPC式架构以及REST-RPC混合架构。 我们会为每一种架构举一个HTTP请求/响应的例子，并给出典型的客户端代码。

第二章 编写Web服务客户端
在这一章，我们教你如何用HTTP库和XML解析器来为现有Web服务编写客户端。 我们将介绍一个流行的REST-RPC服务——del.icio.us Web服务，并用Ruby、Python、Java、C#及PHP等语言来示范其客户端代码。 对于其他一些语言，我们虽然没有展示代码，但会推荐一些适用的HTTP库和XML解析器。 JavaScript和Ajax将在第十一章中作单独介绍。

第三章 REST式服务有什么特别不同？
我们将吸取第二章的经验，并把这些经验运用于一个纯REST式服务——Amazon S3（Simple Storage Service）。 我们将在构建S3客户端时，举例说明一些重要的REST概念： 资源（resource）、表示（representation）、统一接口（uniform interface）。

下面六章是本书的核心，它们关注于如何设计和实现自己的REST式服务。

第四章 面向资源的架构
本章正式介绍REST：不是抽象地介绍，而是以一个具体的Web服务架构为背景进行介绍。 我们的架构基于四个重要的REST概念： 资源、资源名称、资源表示（representation）、以及资源间的链接。 它的服务应根据四个REST特征来评判： 可寻址性、无状态性、连通性和统一接口。

第五章 设计只读的面向资源的服务
我们提出了“把想法或需求转变为REST式资源”的系列步骤。 这些资源是只读的，也就是说客户端可以从服务获取数据，但是不能改变服务的数据。 我们以一个设计地图服务（类似Google Maps）的例子来说明了这些步骤。

第六章 设计可读写的面向资源的服务
我们扩展了上一章的步骤，以允许客户端创建、修改并删除资源。 我们通过为地图服务新增两种资源（用户帐户和自定义地点）为例，示范了这些步骤。

第七章 一个服务实现
我们把一个RPC式服务（即第二章那个del.icio.us REST-RPC混合服务）重构为一个纯REST式服务。 然后，我们把这个服务实现为一个Ruby on Rails应用。 通过这一章，你可以把所学到的知识操练一遍！

第八章 REST和ROA最佳实践
在这一章，我们把之前给出的关于服务设计的建议汇集起来，并补充一些新的建议。 我们将告诉你如何利用HTTP的标准特性来解决常见问题和进行优化。 我们还将为棘手的特性（比如事务，也许你认为这没法用REST式Web服务来实现）给出面向资源的设计。

第九章 服务的技术构件
我们在这一章描述在REST的三大技术（HTTP、URI和XML）之上的其他技术：有些是用于传递状态的文档格式，比如XHTML及其微格式（microformat）； 有些是用于为客户端状态推进的超媒体格式，比如WADL；有些是用于构建REST式Web服务的控制流，比如Atom发布协议。

最后三章涉及一些专门话题，这些专题各自都可单独作为一本书来讨论：

第十章 面向资源的架构 VS 大Web服务
我们将拿我们的架构以及一般的REST架构跟其他著名架构来进行比较。 我们认为REST式Web服务较“基于SOAP、WSDL和WS-*”的服务而言，更为简单、可伸缩性更好、更易于使用、更加符合Web的理念、且更能应付各种各样的客户端。

第十一章 将Ajax应用作为REST客户端
在这一章，我们将以Web服务来阐述用于Web应用的Ajax架构： 一个Ajax应用，就是一个在浏览器里运行的Web服务客户端。 本章是对第二章内容的延伸。我们教你如何用XMLHttpRequest和标准的JavaScript库来编写用于REST式Web服务的客户端。

第十二章 REST式服务的框架
在最后这一章里，我们将讨论三种流行的框架： Ruby on Rails、Restlet（用于Java）和Django（用于Python）。它们可以简化REST式Web服务的开发。

我们还有三个附录，希望对你有用：

附录A REST相关资源与REST式资源
第一部分列出了一些与REST式Web服务有关的标准、教程和社区。 第二部分给出了一些现有的、公开的、可供你调用和学习的REST式Web服务。

附录B 42种常见的HTTP响应代码
这部分解释标准HTTP的每一个响应代码（以及一个扩展），并解释何时你会在REST式Web服务里用到这些代码。

附录C 各种HTTP报头
这部分向你解释各种HTTP报头，包括每个标准的HTTP报头，以及一些用于Web服务的扩展报头。

你应该阅读哪些部分？

本书的组织，适于那些对Web服务的概况感兴趣的读者： 有些读者通过实践学习Web服务，但他们对于Web服务没有太多经验。 如果你属于这种情况，可以采取一条最简化的阅读路线： 从本书开头一直读到第九章，然后在剩下的章节中选择你所感兴趣的部分。 如果你经验比较丰富，那么可以采取另一种阅读路线。 如果你关心如何为现有服务编写客户端，那么可以只关注第一、二、三和第十一章——那些关于服务设计的章节对你可能帮助不大。 如果你想要创建自己的Web服务，或者你想知道REST到底是什么意思，你不妨从第三章开始阅读。如果你想比较REST与WS-*，那么你可以选第一、三、四和第十章作为起点。

说明

本书有两位作者（Leonard和Sam），但在本书其余部分，我们将把这两个身份合并为第一人称“我”。而在最后一章（第十二章）里，这个第一人称“我”代表的是一大群人，因为有众多Django和Restlet开发者们参与到“展示如何用他们的框架来构建REST式服务”中来。

我们假定你是一名胜任的程序员，但不假定你在Web编程方面有任何经验。 我们在书中介绍的内容并不限定于某一编程语言。我们提供了以各种语言编写的REST式客户端及服务的示例代码。 除非为了示范特定的框架或语言，否则我们将采用Ruby（http://www.ruby-lang.org）语言来描述。

我们选用Ruby是因为：即使对于不懂Ruby的程序员来说，它也是简洁易读的。 （因为这是一门很好的语言，而且它的名字跟Sam的姓有着令人困惑的联系。） Ruby的标准Web框架——Ruby on Rails——也是最主要的一种REST式Web服务实现平台之一。 如果你不懂Ruby也没关系， 我们在代码中嵌入了许多有助于理解Ruby语法的注释。

本书的示例程序可以从本书官方网站（http://www.oreilly.com/catalog/9780596529260）上下载，其中包括第七章的Rails应用的完整代码，以及第十二章中Restlet和Django应用的相应代码。在书中，许多客户端我们只给出了Ruby实现；但在示例程序中，你还可以找到它们的Java实现。 这些客户端程序采用了Restlet库，并且是由Restlet开发者Jerome Louvel和Dave Pawson编写的。若相对Ruby而言，你更熟悉Java，那么这些代码对你掌握代码背后的概念会有帮助。 特别值得注意的是，示例代码里还包括一个完整的第三章Amazon S3客户端的Java实现。

[1] Clay Shirky，《In Praise of Evolvable Systems》（http://www.shirky.com/writings/evolve.html）。
[2] 《Legend of The Drunken Protocol》（1991）
[3] Fielding, Roy Thomas. Architectural Styles and the Design of Network-Based Software Architectures, Doctoral dissertation, University of California, Irvine, 2000 (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). 译注：这篇博士论文已经被国内同行翻译为中文版，可以从这里下载http://www.redsaga.com/opendoc/REST_cn.pdf。
[4] 一个早期的例子，请参见Jon Udell于1996年发表在《Byte》杂志上的文章《On-Line Componentware》（http://www.byte.com/ art/9611/sec9/art1.htm）。注： “A powerful capability for ad hoc distributed computing arises naturally from the architecture of the Web.” ——大家注意了，这句话1996年就讲了。