微信号:infoqchina

介绍:有内容的技术社区媒体

理解本真的REST架构风格

2013-09-03 17:44 李锟

本文是“深入探索REST”专栏系列深度内容中的第二篇,它将带您领略REST架构的起源、与Web的关系、REST架构的本质及特性,以及REST架构与其他架构风格之间的比较。


引子


在移动互联网、云计算迅猛发展的今天,作为一名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开发技术的发展可以粗略划分成以下几个阶段:


静态内容阶段:在这个最初的阶段,使用Web的主要是一些研究机构。Web由大量的静态HTML文档组成,其中大多是一些学术论文。Web服务器可以被看作是支持超文本的共享文件服务器。


CGI程序阶段:在这个阶段,Web服务器增加了一些编程API。通过这些API编写的应用程序,可以向客户端提供一些动态变化的内容。Web服务器与应用程序之间的通信,通过CGI(Common Gateway Interface)协议完成,应用程序被称作CGI程序。


脚本语言阶段:在这个阶段,服务器端出现了ASP、PHP、JSP、ColdFusion等支持session的脚本语言技术,浏览器端出现了Java Applet、JavaScript等技术。使用这些技术,可以提供更加丰富的动态内容。


瘦客户端应用阶段:在这个阶段,在服务器端出现了独立于Web服务器的应用服务器。同时出现了Web MVC开发模式,各种Web MVC开发框架逐渐流行,并且占据了统治地位。基于这些框架开发的Web应用,通常都是瘦客户端应用,因为它们是在服务器端生成全部的动态内容。


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公司所有)等等。


移动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的博士论文(中文版名为《架构风格与基于网络的软件架构设计》)中,提出了一整套基于网络的软件(即所谓的“分布式应用”)的设计方法,值得所有分布式应用的开发者仔细阅读、深入体会。


在论文的前三章中,Fielding在批判性继承前人研究成果的基础上,建立起来一整套研究和评价软件架构的方法论。这套方法论的核心是“架构风格”这个概念。架构风格是一种研究和评价软件架构设计的方法,它是比架构更加抽象的概念。一种架构风格是由一组相互协作的架构约束来定义的。架构约束是指软件的运行环境施加在架构设计之上的约束。


在论文的第四章中,Fielding研究了Web这样一个分布式系统对于软件架构设计提出了哪些需求。在第五章中,Fielding将第四章Web提出的需求具体化为一些架构约束,通过逐步添加各种架构约束,推导出来了REST这种新的架构风格。


REST架构风格最重要的架构约束有6个:


客户-服务器(Client-Server):通信只能由客户端单方面发起,表现为请求-响应的形式。


无状态(Stateless):通信的会话状态(Session State)应该全部由客户端负责维护。


缓存(Cache):响应内容可以在通信链的某处被缓存,以改善网络效率。


统一接口(Uniform Interface):通信链的组件之间通过统一的接口相互通信,以提高交互的可见性。


分层系统(Layered System):通过限制组件的行为(即,每个组件只能“看到”与其交互的紧邻层),将架构分解为若干等级的层。


按需代码(Code-On-Demand,可选):支持通过下载并执行一些代码(例如Java Applet、Flash或JavaScript),对客户端的功能进行扩展。


……


注:原文较长,这儿为部分节选内容,请点击原文链接查看全文。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 前端汪关注:手机版专题页面的注意事项 IBM带你看第七届中国云计算大会 在Systrace中添加 mutex lock owner Mac下提升工作效率的方式 Python基础教程15:列表(Lists)