rest

本文是“深入探索REST”专栏系列深度内容中的第二篇，它将带您领略REST架构的起源、与Web的关系、REST架构的本质及特性，以及REST架构与其他架构风格之间的比较。引子在移动互联网、云计算迅猛发展的今天，作为一名Web开发者，如果您还没听说过“REST”这个buzzword，显然已经落伍了。夸张点说，甚至“出了门都不好意思跟别人打招呼”。尽管如此，对于REST这个泊来品的理解，大多数人（包括一些资深的架构师）仍然停留在“盲人摸象”的阶段。常常听到各种各样关于REST的说法，例如：有人说：“我们这套新的API决定不用WebService（SOAP+WSDL），而是直接使用HTTP+JSON，也就是用RESTful的方式来开发。”不用SOAP，甚至也不用XML，就自动变成了RESTful了。还有人认为：REST与传统的WebService其实没有本质区别，只是对于URI的构造方式提出了更多要求，而这些要求WebService完全都可以实现。潜台词是：既生瑜，何生亮。WebService已经足够好了，干嘛还要再折腾什么REST。这些对于REST的不同说法，果真如此吗？REST究竟是什么？是一种新的技术、一种新的架构、还是一种新的规范？对于这些问题笔者先不解答，为了深入理解REST是什么，我们需要回顾一下Web发展的最初年代，从源头上讲讲REST是怎么得来的。Web技术发展与REST的由来Web（万维网WorldWideWeb的简称）是个包罗万象的万花筒，不同的人从不同的角度观察，对于Web究竟是什么会得出大不相同的观点。作为Web开发者，我们需要从技术上来理解Web。从技术架构层面上看，Web的技术架构包括了四个基石：URIHTTPHyperText（除了HTML外，也可以是带有超链接的XML或JSON）MIME这四个基石相互支撑，促使Web这座宏伟的大厦以几何级数的速度发展了起来。在这四个基石之上，Web开发技术的发展可以粗略划分成以下几个阶段：1.静态内容阶段：在这个最初的阶段，使用Web的主要是一些研究机构。Web由大量的静态HTML文档组成，其中大多是一些学术论文。Web服务器可以被看作是支持超文本的共享文件服务器。2.CGI程序阶段：在这个阶段，Web服务器增加了一些编程API。通过这些API编写的应用程序，可以向客户端提供一些动态变化的内容。Web服务器与应用程序之间的通信，通过CGI（CommonGatewayInterface）协议完成，应用程序被称作CGI程序。3.脚本语言阶段：在这个阶段，服务器端出现了ASP、PHP、JSP、ColdFusion等支持session的脚本语言技术，浏览器端出现了JavaApplet、JavaScript等技术。使用这些技术，可以提供更加丰富的动态内容。4.瘦客户端应用阶段：在这个阶段，在服务器端出现了独立于Web服务器的应用服务器。同时出现了WebMVC开发模式，各种WebMVC开发框架逐渐流行，并且占据了统治地位。基于这些框架开发的Web应用，通常都是瘦客户端应用，因为它们是在服务器端生成全部的动态内容。5.RIA应用阶段：在这个阶段，出现了多种RIA（RichInternetApplication）技术，大幅改善了Web应用的用户体验。应用最为广泛的RIA技术是DHTML+Ajax。Ajax技术支持在不刷新页面的情况下动态更新页面中的局部内容。同时诞生了大量的Web前端DHTML开发库，例如Prototype、Dojo、ExtJS、jQuery/jQueryUI等等，很多开发库都支持单页面应用（SinglePageApplication）的开发。其他的RIA技术还有Adobe公司的Flex、微软公司的Silverlight、Sun公司的JavaFX（现在为Oracle公司所有）等等。6.移动Web应用阶段：在这个阶段，出现了大量面向移动设备的Web应用开发技术。除了Android、iOS、WindowsPhone等操作系统平台原生的开发技术之外，基于HTML5的开发技术也变得非常流行。从上述Web开发技术的发展过程看，Web从最初其设计者所构思的主要支持静态文档的阶段，逐渐变得越来越动态化。Web应用的交互模式，变得越来越复杂：从静态文档发展到以内容为主的门户网站、电子商务网站、搜索引擎、社交网站，再到以娱乐为主的大型多人在线游戏、手机游戏。在互联网行业，实践总是走在理论的前面。Web发展到了1995年，在CGI、ASP等技术出现之后，沿用了多年、主要面向静态文档的HTTP/1.0协议已经无法满足Web应用的开发需求，因此需要设计新版本的HTTP协议。在HTTP/1.0协议专家组之中，有一位年轻人脱颖而出，显示出了不凡的洞察力，后来他成为了HTTP/1.1协议专家组的负责人。这位年轻人就是ApacheHTTP服务器的核心开发者RoyFielding，他还是Apache软件基金会的合作创始人。RoyFielding和他的同事们在HTTP/1.1协议的设计工作中，对于Web之所以取得巨大成功，在技术架构方面的因素做了一番深入的总结。Fielding将这些总结纳入到了一套理论框架之中，然后使用这套理论框架中的指导原则，来指导HTTP/1.1协议的设计方向。HTTP/1.1协议的第一个草稿是在1996年1月发布的，经过了三年多时间的修订，于1999年6月成为了IETF的正式规范（包括了RFC2616以及用于对客户端做身份认证的RFC2617）。HTTP/1.1协议设计的极为成功，以至于发布之后整整10年时间里，都没有多少人认为有修订的必要。用来指导HTTP/1.1协议设计的这套理论框架，最初是以备忘录的形式在专家组成员之间交流，除了IETF/W3C的专家圈子，并没有在外界广泛流传。Fielding在完成HTTP/1.1协议的设计工作之后，回到了加州大学欧文分校继续攻读自己的博士学位。第二年（2000年）在他的博士学位论文ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures中，Fielding更为系统、严谨地阐述了这套理论框架，并且使用这套理论框架推导出了一种新的架构风格，并且为这种架构风格取了一个令人轻松愉快的名字“REST”——RepresentationalStateTransfer（表述性状态转移）的缩写。在笔者看来，Fielding这篇博士论文在Web发展史上的价值，不亚于Web之父TimBerners-Lee关于超文本的那篇经典论文。然而遗憾的是，这篇博士论文在诞生之后的将近5年时间里，一直没有得到足够的重视。例如WebService相关规范SOAP/WSDL的设计者们，显然不大理解REST是什么，HTTP/1.1究竟是一个什么样的协议、为何要设计成这个样子。这种情况在2005年之后有了很大的改善，随着Ajax、RubyonRails等新的Web开发技术的兴起，在Web开发技术社区掀起了一场重归Web架构设计本源的运动，REST架构风格得到了越来越多的关注。在2007年1月，支持REST开发的RubyonRails1.2版正式发布，并且将支持REST开发作为Rails未来发展中的优先内容。RubyonRails的创始人DHH做了一个名为“WorldofResources”的精彩演讲，DHH在Web开发技术社区中的强大影响力，使得REST一下子处在Web开发技术舞台的聚光灯之下。今天，各种流行的Web开发框架，几乎没有不支持REST开发的了。大多数Web开发者都是通过阅读某种REST开发框架的文档，以及通过一些例子代码来学习REST开发的。然而，通过例子代码来学习REST有非常大的局限性。因为REST并不是一种具体的技术，也不是一种具体的规范，REST其实是一种内涵非常丰富的架构风格。通过例子代码来学习REST，除了学习到一种有趣的Web开发技术之外，并不能全面深入的理解REST究竟是什么。甚至还会误以为这些简单的例子代码就是REST本身，REST不过是一种简单的Web开发技术而已。就像盲人摸象一样，有的人摸到了象鼻子、有的人摸到了象耳朵、有的人摸到了象腿、有的人摸到了象尾巴。他们都坚信自己感觉到的大象，才是最真实的大象，而其他人的感觉都是错误的。对于不理解REST的Web开发者，人们习惯于展示一些例子代码来让他们理解REST，笔者不赞同上述做法。如果Web开发者想要深入理解REST是什么，就很难避开Fielding的这篇博士论文。笔者在本文中对于REST是什么的介绍，也是基于Fielding的博士论文的。尽管如此，笔者强烈建议本文的读者亲自去通读一下Fielding的博士论文，就像想要了解孔子的思想应该直接去读《论语》等著作，而不是首先去读其他人的转述一样。笔者在本文中也仅仅是努力不做一个把经书念错了的歪嘴和尚而已。那么，下面我们言归正传。在Fielding的这篇名为ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures的博士论文（中文版名为《架构风格与基于网络的软件架构设计》）中，提出了一整套基于网络的软件（即所谓的“分布式应用”）的设计方法，值得所有分布式应用的开发者仔细阅读、深入体会。在论文的前三章中，Fielding在批判性继承前人研究成果的基础上，建立起来一整套研究和评价软件架构的方法论。这套方法论的核心是“架构风格”这个概念。架构风格是一种研究和评价软件架构设计的方法，它是比架构更加抽象的概念。一种架构风格是由一组相互协作的架构约束来定义的。架构约束是指软件的运行环境施加在架构设计之上的约束。在论文的第四章中，Fielding研究了Web这样一个分布式系统对于软件架构设计提出了哪些需求。在第五章中，Fielding将第四章Web提出的需求具体化为一些架构约束，通过逐步添加各种架构约束，推导出来了REST这种新的架构风格。REST架构风格的推导过程如下图所示：图1：REST所继承的架构风格约束（原图可在这里下载）在图1中，每一个椭圆形里面的缩写词代表了一种架构风格，而每一个箭头边的单词代表了一种架构约束。REST架构风格最重要的架构约束有6个：客户-服务器（Client-Server）通信只能由客户端单方面发起，表现为请求-响应的形式。无状态（Stateless）通信的会话状态（SessionState）应该全部由客户端负责维护。缓存（Cache）响应内容可以在通信链的某处被缓存，以改善网络效率。统一接口（UniformInterface）通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。分层系统（LayeredSystem）通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。按需代码（Code-On-Demand，可选）支持通过下载并执行一些代码（例如JavaApplet、Flash或JavaScript），对客户端的功能进行扩展。在论文中推导出的REST架构风格如下图所示：图2：REST架构风格（原图可在这里下载）而HTTP/1.1协议作为一种REST架构风格的架构实例，其架构如下图所示：图3：一个基于REST的架构的过程视图（原图可在这里下载）用户代理处在三个并行交互（a、b和c）的中间。用户代理的客户端连接器缓存无法满足请求，因此它根据每个资源标识符的属性和客户端连接器的配置，将每个请求路由到资源的来源。请求（a）被发送到一个本地代理，代理随后访问一个通过DNS查找发现的缓存网关，该网关将这个请求转发到一个能够满足该请求的来源服务器，服务器的内部资源由一个封装过的对象请求代理（objectrequestbroker）架构来定义。请求（b）直接发送到一个来源服务器，它能够通过自己的缓存来满足这个请求。请求（c）被发送到一个代理，它能够直接访问WAIS（一种与Web架构分离的信息服务），并将WAIS的响应翻译为