专访和样章试读：RESTful Web Services

**InfoQ 发布了由 Leonard Richardso 和 Sam Ruby 联合撰写的“ RESTful Web Services ”一书的样本章节。该书介绍了REST 架构的原则，并解释如何使用Ruby on Rails、Restlel 和Django 构建基于REST 的应用。借此机会，InfoQ 的Stefan Tilkov 采访了该书作者，讨论关于写作该书的背景以及他们对REST 和Web 服务的看法。** InfoQ：Leonard，什么原因促使你写一本关于 REST 的书呢？

LR：我自 1998 年以来一直从事互联网应用开发。 在这期间，有些比我年龄大的人试图规范互联网并把其抽象成大家熟悉的编程环境。其结果更像我试图避免的分布式计算环境，而不是我所喜欢的互联网应用环境。

这几年来我对此深感厌烦，并认识到 REST 可能是一种更具优势的规范取向。 但在阅读 Bill de heOra 的博客之前（他应该成为该书的致谢人员之一），我并没有在 REST 方面有所作为。Bill 在博客中提到了 REST/HTTP 书籍的必要性，而当时我刚好完成 Ruby Cookbook 一书，我想我不就是写书的吗？于是我就开始了。

InfoQ：Sam，你曾经参与了 Web 服务的创始和 SOAP 构建软件项目，也是 ApacheSOAP 的开发人员之一。什么原因促使你转变观念并倾向于 REST？还是说根本就没有这种转变？

SR：噢，这当然涉及到观念的转变。让我改变想法的是 Rael Dornfest 撰写的 Bloxon 代码库。在接触这些代码之前，我一直假设认为网络需要进行封装并抽象出来。Bloxon 代码库没有任何依赖性，但却因不做任何假设而显得更简单，更有力，更易于维护，和更具适应性。同时我也注意到开源的 SOAP 堆栈越来越多，但真正部署 SOAP Web 服务的应用并不多。

InfoQ：你能否对 REST 作最简单的介绍？REST 到底有什么好处？

SR：优化并最大限度地使用 GET。

LR：让我对 SAM 的简短介绍再补充一句： 以 URI 标识所有计算资源。

今天 REST 的好处无所不在。 以前大家通过邮寄、电话及 IP 协议，如 FTP 和 WAIS 处理许多日常活动，今天大家都通过 Web 进行这些活动。Web 接口（如 HTTP、连接、表格等）十分简单，但它足以封装各种不同的日常活动。所有 Web 应用因为基于同一工作原理而显得简单易用，并附带诸如“页面排行”等新兴应用属性。

刚才我提到了一些模糊的概念，诸如简单、封装以及所有的事情按照一种方式工作等，这正是对 REST 的正式描述。当你以 REST 解决分布式计算问题时（正像本书所做的），你拥有简单的架构但却避免了分布式计算中的诸多头疼问题。

InfoQ：你刚才提到 GET 的重要性。可不可以说 REST 只适合大多只读的 Web 应用，而不适合高流量和经常可写的 Web 应用？

LR：我认为 REST 的架构适合任何 Web 服务应用，但只读应用更易于说明问题。一个只读的 Web 服务应用与一个只读的网页工作原理是一样的。我们通过 GET 提供数据已经 15 年了，我们知道如何去做。我们拥有各种编程语言的客户端编码库，调试工具，以及透明 中继服务如缓存代理服务器。

但大部分网站并未通过 REST 方式提供可写操作。大部分应用倾向于把操作的名称变成 URI 的一部分，比如 story/publish 和 product/add -to -cart。真正的 REST 应用需要遵循统一的接口命名约束。这意味着 URI 只能用于识别某种对象，如 /story 和 /product，而 Web 服务应用可通过发送消息改变这些对象的状态。

这不是一种巨大的观念超越，但它与今天 的做法恰恰相反，也就不那么容易被接受了。只读 REST 应用拥有大量的工具和规则，而可写 REST 应用则没有。人们至今还在争论可写 REST 应用的消息格式，以及 POST+PUT+DELET 是否应该改变状态还是只要 POST 就可以了呢。

SR：我从事过一些数据应用的开发，我的经验是大部分应用 90% 以上代码是读取数据。日志应用是个例外，但订单管理应用却不是这么回事。

我也坦诚承认 REST 不能解决所有问题，但我认为 REST 不能解决的问题，WS-* 也是不适用的。

InfoQ：一种常见的 REST 反对意见是 REST 不过是分布式超媒体系统，也就是说，一种为最终用户传送文档而设计的系统，尽管这种文档可能动态生成。你怎么解释它也适合机器与机器的交互呢？

LR：一个超媒体系统由两个组成部分，即对象以及对象间的关联。数据建模也可由这两部分组成。任何数据的一部分是关于结构信息的，另一部分则是关于和其它信息结构的关联关系。所以超媒体系统是让客户端发掘数据结构的理想方式，而计算机几乎是与人类一样的方式使用超媒体文档：首先机器可以检阅一下数据内容，并查看是否有其兴趣的连接，有的话则再跟进其感兴趣的关联。

一个典型的用例是 Amazon S3，这种 REST 风格的 Web 服务很好地展现了树形结构的数据： 它由包含对象的容器组成，如果客户端是 GET 一个容器，其将获得一个 XML 文档包含了该容器里所有对象的命名列表。在计算机语言里这可表示为与实际对象关联的指针列表，也就是可以通过 GET 获得其他对象的关联列表。

当然，我并不推荐这种很原始的做法。最好的做法是以 URI 关联对象，而那份列表则是以 URI 表示的对象命名清单。开发 S3 应用必须遵循规则把对象解释成可以 GET 或 PUT 的 URI 格式。这些以 URI 表示的名字实际就是超媒体连接，这些连接则指向其他的对象实体。

SR：实际的结果是 S3 客户端仅是针对于 S3 或 S3 类似的系统。相比较而言，Web 客户端则是针对于整个 Web。由 Web 推动的最成功应用（及商业模式）之一就是搜索。如果大家查看一下各网站的所有请求，就可发现其中有一大部分的请求来自网络爬虫，网络爬虫是能够解释超连接语义的应用软件。另外，还有很多应用为了把搜索结果进行排行而使用超连接作为元数据。

总的来说，大部分应用都有是状态机。WS-* 把状态放在消息信封里，而 REST 则以 URI 这种简单的形式表示状态。

InfoQ：还有一种常见的争议，其声称被 Web 证明成功的 REST 优势是错误的，因为大部分 Web 应用并未遵循 REST 风格。

LR：这种观点有其真实性的一面，我前面说过现有大多网站的可写应用并未遵循 REST 风格。但我想如果遵循 REST 风格将使 Web 应用变得更好，而并不影响 Web 的成功。当然，如果浏览器以 REST 风格的严格性限制无效 HTML 的使用，那将严重影响 Web 的成功。我说这话是基于为 REST 一书曾写过的某个章节，这个章节探索了 Web 成功的各种原因。我们最后把它删去了是因为没有多少人对 Web 和 Gopher 网络 的详细比较感兴趣——除了我和 Rohit Khare。但基本上是可以归纳为三种重要的原因： 所有东西都可用网址识别，网页之间互相关联，只需游览器即可操作整个 Web。

头两个原因与 REST 风格的 Web 服务一致：可用 URI 表示计算资源的地址，以及超媒体系统作为 Web 应用状态机（在书中作为“连接性”提到）。我并不想以 Web 的成功作为提倡 REST 的依据，而是要指出 URI 以及连接的无穷用处，这常常为 WS-* 所忽略。

InfoQ：很显然越来越多的人开始认真考虑 REST。几年前，只有少数的 REST 先驱提倡者，现在大家好像都在考虑 REST 这一选择。甚至包括微软和 Sun 。你认为 REST 正在胜出了吗？你认为有这种可能吗？

LR：正在胜出是可能的，虽然至今还有许多 FTP 站点和邮寄目录杂志，但我很少使用。至少对于我来说，Web 已经胜出了。我的简单预言是 WS-* 架构不会长期适合面向公众的或高流量的应用。我最大的疑问是，那些有意识地以 REST 设计的基本架构是否将会胜出那些偶尔遵循 REST 风格且简单的架构（如 Flicker 的 REST API）。

SR：在多层次的框架上添加一层轻量的看似 REST 的接口，这当然渐成流行。一种识别伪装者的 InfoQ 式提问是“你支持 Etag 吗？”。任一回答都可视为正确答案，包括无任何借口或关系的自信回答“不”。

SR：当并未提及 HTTP 的 REST 正式定义与具体 Web 服务设计存在巨大鸿沟时，这种现象是可以理解的。本书的主要目的就是为读者提供一种简单易用而又严格遵循 REST 风格的指导性架构。

InfoQ：与 WS-* 比较，REST 具备哪些优势呢？

LR：主要的优势之一是把服务的控制权交给了用户。如果数据是通过大量的资源形式展示给用户，那么用户就可以最少量的软件堆栈获取数据。若以 URI 表示计算资源，用户可将 URI 传给其他服务形成应用组合。当计算资源通过连接相互关联时，用户就无需内化许多复杂计算规则即可任意搜索。

SR：相应地，REST 所规定的一致性与约束使之成为可能。实际上，并不是每个 SOAP 都是复杂的，但可以说每个 SOAP 服务的 WSDL 都需定制而且不同，正是这种为每个服务端点确立一套不同规则造成了系统的复杂性。

InfoQ：你觉得 REST 和 WS-* 可以共处吗？

SR：有许多技术如 ActiveX 在企业内网得到普遍应用，但并不适用于互联网。我觉得 WS-* 也像这类技术。如果你有少量具有足够互信的系统并想在其之间部署 WS-Federation，这并没有什么不可以。

LR：正如 Sam 所说的，在自己所能掌控的异构环境下，其网络效应是不一样的，此时使用 ActiveX 或实现一些感兴趣的 WS-* 标准是可行的。

InfoQ：哪些应用功能 WS-* 支持良好但 REST 略逊一筹呢？

SR：理论上，双方都描述了相应的功能领域，诸如把认证与授权的信息放在标题里。在现实中 WS-* 对安全考虑得更多。REST 社区若想有所作为的话，在将来这种差距是可以消除的，但在今天来说这是个事实。

LR：我希望尽快消除这种差距。需要 WS-Security 令牌 的用户应该可以用 HTTP 安全延伸模块（即 WSSE）实现，其他 SOAP 标题和 WS-* 标题 也可以同样方式实现。

另一种缺陷是服务接口描述。客户端开发人员很喜欢统一的接口描述，虽然有些人认为这在 REST 世界里是不切实际的。我认为 WADL 将在这方面发挥重要作用。

另一个相关的话题是开发工具支持，而且我有些担心开发工具将让 REST 服务应用变得类似 RPC 应用，但人们仍声称支持 REST。但从现有的开发工具看来，诸如 Restlet、Rails 1.2 以及 Thomas Stemer 的 REST Describe，都很好地把握了 REST 的原则。

InfoQ：二位要不要给我们简单介绍一下这本书？ 在你写书时心中假定的读者是怎样？

LR：我假想这些人就像我自己刚开始写书时一样：对 REST 感兴趣但不太确定自己是否正确应用了理论。

SR：我也想让该书避免落入 REST 狂热分子的俗套。但这并不代表说该书未能坚持己见。我们还是坚持己见的，着重于实际应用，权衡利弊，甚至不得不面对未能一致地应用理论的混乱现实。

InfoQ：十分感谢二位的时间！

查看英文原文： Interview and Book Excerpt: RESTful Web Services - - - - - -

译者简介：林伯仲， IONA 科技公司亚太研发中心研发经理。他和他的北京同事目前致力于 SOA 基础架构软件研发，并共同参与多个 SOA 及 Web 服务开源项目，包括 Eclipse STP 和 Apache CXF 等。