理解本真的REST架构风格

本文是“深入探索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这种 新的架构风格。

时间: 2025-01-19 17:50:14

理解本真的REST架构风格的相关文章

【转载】理解本真的REST架构风格

      本文将带您领略REST架构的起源.与Web的关系.REST架构的本质及特性,以及REST架构与其他架构风格之间的比较. 引子       在移动互联网.云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过"REST"这个buzzword,显然已经落伍了.夸张点说,甚至"出了门都不好意思跟别人打招呼".尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在"盲人摸象"的阶段.常常听到各种各样关于RES

Web基础架构设计原则经典论文《架构风格与基于网络的软件架构设计》导读

1. 概述 Roy Fielding博士(见个人主页)是IETF发布的HTTP和URI协议的主要设计者.HTTP和URI是两个最为重要的Web基础技术架构协议,因此Fielding博士可谓是Web架构的奠基者之一. 除了学术上的卓越成就之外,Fielding博士还参与过很多开源软件的设计和开发工作.他是libwww-perl(世界上最早的HTTP开发库之一)的开发者,曾经负责Apache HTTP服务器中与HTTP.URI协议相关部分代码的开发.Fielding博士还指导过很多其他团队在HTTP

架构风格

管道-过滤器风格:每个构建都有一组输入和输出,数据输入构建,经过内部处理,然后产生数据输出. 主程序-子程序:面向过程的架构,所有的计算构件作为子程序协作工作,并由一个主程序顺序的调用这些子程序,构件用共享存储区交换数据. 面向对象风格:面向对象架构风格的特征是将数据标识和基本操作封装在对象中.这种模式的构件是对象,对象维护自身表示的完整性,对象之间通过消息机制进行通信,对象交互时需要知道彼此的标识,通过对象之间的协作完成计算过程. 面向对象好处: 1. 可以自然映射到现实对象上,易于理解和编程

学习顺便翻译:理解jsp模式2架构——MVC设计模式探险

js|架构|设计 理解jsp模式2架构 MVC设计模式探险 摘要:通过开发一个熟悉的基于web的购物店,你将学到如何工具化mvc设计模式并且真正地在使用jsp的时候分离内容和表现.Govind Seshadri 会向你展示这是多么的容易(2000字(原文字数)). 作者:Govind Seshadri 尽管相对抛开最近的相关介绍而言,jsp技术正在很好地以自己的方式成为卓越的创建提供动态web内容的应用程序的java技术.java开发者因为许多不同的理由喜爱jsp.一些人喜欢它给交互式web页面

RESTful架构风格下的4大常见安全问题|洞见

一.遗漏了对资源从属关系的检查  一个典型的RESTful的URL会用资源名加上资源的ID编号来标识其唯一性,就像这样/users/100 一般而言用户只能查看自己的用户信息,而不允许查看其它用户的信息.在这种情况下,攻击者很可能会尝试把这个URL里面的USER ID从100修改为其他数值,以期望应用返回指定用户的信息.不过由于这个安全风险太显而易见,绝大多数应用都会对当前请求者的身份进行校验,看其是否是编号为100的用户,校验成功才返回URL中指定的用户信息,否则会拒绝当前请求.  对于URL

理解jsp模式2架构:MVC设计模式探险

js|架构|设计 摘要:通过开发一个熟悉的基于web的购物店,你将学到如何工具化mvc设计模式并且真正地在使用jsp的时候分离内容和表现.Govind Seshadri 会向你展示这是多么的容易(2000字(原文字数)). 尽管相对抛开最近的相关介绍而言,jsp技术正在很好地以自己的方式成为卓越的创建提供动态web内容的应用程序的java技术.java开发者因为许多不同的理由喜爱jsp.一些人喜欢它给交互式web页面带来了"一次编写,到处运行"的变化这个事实:另一些人欣赏它易学易用并且

架构师之路-在Dubbo中开发REST风格的远程调用

概述 dubbo支持多种远程调用方式,例如dubbo RPC(二进制序列化 + tcp协议).http invoker(二进制序列化 + http协议,至少在开源版本没发现对文本序列化的支持).hessian(二进制序列化 + http协议).WebServices (文本序列化 + http协议)等等,但缺乏对当今特别流行的REST风格远程调用(文本序列化 + http协议)的支持. 有鉴于此,我们基于标准的Java REST API--JAX-RS 2.0(Java API for REST

微服务与SOA架构

本文讲的是微服务与SOA架构[编者的话]本文是Mark Richards写的微服务与面向服务架构完整报告. 基于服务架构的世界 微服务和SOA都被认为是基于服务的架构,这意味着这两种架构模式都非常强调将"服务"作为其架构中的首要组件,用于实现各种功能(包括业务层面和非业务层面).微服务和SOA是两种差异很大的架构模式,但是他们仍有一些相同的特征. 所有基于服务的架构的一个共性是他们一般都是分布式架构,也就是服务组件都是通过远程访问协议来实现的,例如REST.SOAP.AMQP.JMS.

RESTful架构详解(转)

1. 什么是REST REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移. 它首次出现在2000年Roy Fielding的博士论文中,Roy Fielding是HTTP规范的主要编写者之一. 他在论文中提到:"我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强.性能好.适宜通信的架构.REST指的是一组架构约束条件和原则." 如果一个架构符合REST