您的位置:知识库 » 软件设计

理解本真的REST架构风格

作者: 李锟  来源: InfoQ  发布时间: 2013-11-22 18:28  阅读: 29265 次  推荐: 24   原文链接   [收藏]  

  引子

  在移动互联网、云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个buzzword,显然已经落伍了。夸张点说,甚至“出了门都不好意思跟别人打招呼”。尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在“盲人摸象”的阶段。常常听到各种各样关于REST的说法,例如:有人说:“我们这套新的API决定不用Web Service(SOAP+WSDL),而是直接使用HTTP+JSON,也就是用RESTful的方式来开发。”

  不用SOAP,甚至也不用XML,就自动变成了RESTful了。还有人认为:REST与传统的Web Service其实没有本质区别,只是对于URI的构造方式提出了更多要求,而这些要求Web Service完全都可以实现。潜台词是:既生瑜,何生亮。Web Service已经足够好了,干嘛还要再折腾什么REST。这些对于REST的不同说法,果真如此吗?REST究竟是什么?是一种新的技术、一种新的架构、还是一种新的规范?

  对于这些问题笔者先不解答,为了深入理解REST是什么,我们需要回顾一下Web发展的最初年代,从源头上讲讲REST是怎么得来的。

  Web技术发展与REST的由来

  Web(万维网World Wide Web的简称)是个包罗万象的万花筒,不同的人从不同的角度观察,对于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(Common Gateway Interface)协议完成,应用程序被称作CGI程序。
  3. 脚本语言阶段:在这个阶段,服务器端出现了ASP、PHP、JSP、ColdFusion等支持Session的脚本语言技术,浏览器端出现了Java Applet、JavaScript等技术。使用这些技术,可以提供更加丰富的动态内容。
  4. 瘦客户端应用阶段:在这个阶段,在服务器端出现了独立于Web服务器的应用服务器。同时出现了Web MVC开发模式,各种Web MVC开发框架逐渐流行,并且占据了统治地位。基于这些框架开发的Web应用,通常都是瘦客户端应用,因为它们是在服务器端生成全部的动态内容。
  5. RIA应用阶段:在这个阶段,出现了多种RIA(Rich Internet Application)技术,大幅改善了Web应用的用户体验。应用最为广泛的RIA技术是DHTML+Ajax。Ajax技术支持在不刷新页面的情况下动态更新页面中的局部内容。同时诞生了大量的Web前端DHTML开发库,例如Prototype、Dojo、ExtJS、jQuery/jQuery UI等等,很多开发库都支持单页面应用(Single Page Application)的开发。其他的RIA技术还有Adobe公司的Flex、微软公司的Silverlight、Sun公司的JavaFX(现在为Oracle公司所有)等等。
  6. 移动Web应用阶段:在这个阶段,出现了大量面向移动设备的Web应用开发技术。除了Android、iOS、Windows Phone等操作系统平台原生的开发技术之外,基于HTML5的开发技术也变得非常流行。

  从上述Web开发技术的发展过程看,Web从最初其设计者所构思的主要支持静态文档的阶段,逐渐变得越来越动态化。Web应用的交互模式,变得越来越复杂:从静态文档发展到以内容为主的门户网站、电子商务网站、搜索引擎、社交网站,再到以娱乐为主的大型多人在线游戏、手机游戏。

  在互联网行业,实践总是走在理论的前面。Web发展到了1995年,在CGI、ASP等技术出现之后,沿用了多年、主要面向静态文档的HTTP/1.0协议已经无法满足Web应用的开发需求,因此需要设计新版本的HTTP协议。在HTTP/1.0协议专家组之中,有一位年轻人脱颖而出,显示出了不凡的洞察力,后来他成为了HTTP/1.1协议专家组的负责人。这位年轻人就是Apache HTTP服务器的核心开发者Roy Fielding,他还是Apache软件基金会的合作创始人。

  Roy Fielding和他的同事们在HTTP/1.1协议的设计工作中,对于Web之所以取得巨大成功,在技术架构方面的因素做了一番深入的总结。Fielding将这些总结纳入到了一套理论框架之中,然后使用这套理论框架中的指导原则,来指导HTTP/1.1协议的设计方向。HTTP/1.1协议的第一个草稿是在1996年1月发布的,经过了三年多时间的修订,于1999年6月成为了IETF的正式规范(包括了RFC 2616以及用于对客户端做身份认证的RFC 2617)。

  HTTP/1.1协议设计的极为成功,以至于发布之后整整10年时间里,都没有多少人认为有修订的必要。用来指导HTTP/1.1协议设计的这套理论框架,最初是以备忘录的形式在专家组成员之间交流,除了IETF/W3C的专家圈子,并没有在外界广泛流传。Fielding在完成HTTP/1.1协议的设计工作之后,回到了加州大学欧文分校继续攻读自己的博士学位。第二年(2000年)在他的博士学位论文Architectural Styles and the Design of Network-based Software Architectures中,Fielding更为系统、严谨地阐述了这套理论框架,并且使用这套理论框架推导出了一种新的架构风格,并且为这种架构风格取了一个令人轻松愉快的名字“REST”——Representational State Transfer(表述性状态转移)的缩写。

  在笔者看来,Fielding这篇博士论文在Web发展史上的价值,不亚于Web之父Tim Berners-Lee关于超文本的那篇经典论文。然而遗憾的是,这篇博士论文在诞生之后的将近5年时间里,一直没有得到足够的重视。例如Web Service相关规范SOAP/WSDL的设计者们,显然不大理解REST是什么,HTTP/1.1究竟是一个什么样的协议、为何要设计成这个样子。

  这种情况在2005年之后有了很大的改善,随着Ajax、Ruby on Rails等新的Web开发技术的兴起,在Web开发技术社区掀起了一场重归Web架构设计本源的运动,REST架构风格得到了越来越多的关注。在2007年1月,支持REST开发的Ruby on Rails 1.2版正式发布,并且将支持REST开发作为Rails未来发展中的优先内容。Ruby on Rails的创始人DHH做了一个名为“World of Resources”的精彩演讲,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的这篇名为Architectural Styles and the Design of Network-based Software Architectures的博士论文(中文版名为《