专访和样章试读：RESTful Web Services
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等。