REST 与面向资源的 Web开发深入理解 Web 的架构风

格

主讲人：李锟 (dlee)

#

我是谁• 14 年工作经验， 8 年 Web 应用、 3 年企业应用、 3 年电信协议• 《 J2EE Development without EJB 》、《 Ajax in Action 》、

《 Ajax Patterns and Best Practices 》、《 REST in Practice 》中文版的译者

• Roy Fielding 的博士论文《 Architectural Styles and the Design of Network-based Software Architectures 》中文版的译者

• “REST 实战”讨论组的负责人• http://groups.google.com/group/rest_in_action

• 现任职于阿里巴巴 B2B 的平台技术部

#

讲座内容• 什么是 Web• 什么是 REST• REST 的架构约束• REST 的五个关键词• REST 风格架构的主要特

征• REST 风格架构的设计步

骤• REST 与安全性

• REST 风格架构带来的好处

• 关于 HTTP 的一些误解• 关于 REST 的一些误解• 各种编程语言对于 REST

的支持• REST 与 Web 服务• REST 与 SOA• REST 不适用的场合

#

什么是 Web• World Wide Web( 万维网 ) ，简称 WWW 或

Web• 浏览器？ HTML ？ Ajax ？ Flash ？ Web 2.0 ？• Web 的三大技术基石• URI ：用来标识资源• HTTP ：用来操作资源• Hypertext ：用来描述资源的状态

• HTML• XML• JSON/ 纯文本

#

什么是 Web( 续 )• 定义“ Web 应用”

• 使用了上述三大技术• 运行在 Internet 环境中• 与“企业应用”相对• 广义的 Web 应用

• 包括所有使用了上述三大技术的应用• 狭义的 Web 应用

• 仅包括运行于浏览器中的应用• 与“桌面应用”相对

• Web 已死？

#

什么是 REST• Representational State Transfer( 表述性状态转

移 ) ，简称 REST• 来自 Roy Fielding 的博士论文：《 Architectural Styles and the

Design of Network-based Software Architectures 》 ( 《架构风格与基于网络的软件架构设计》 )

• Roy Fielding 是何许人• Day Software 公司的首席科学家， Apache 软件基金会的合作创

始人，在美国加洲大学欧文分校获得博士学位• HTTP 、 URI 等 Web 基础协议的主要设计者

• “REST 实战”讨论组中有这篇论文的导读

#

什么是 REST( 续 )• Web 自身的架构风格 (Architectural Style)

• 架构风格的概念来自建筑学，比架构更为抽象• 例子：分布式对象（ DO）、远程过程调用（ RPC）• 类比：接口 - 实现 或 类 - 实例

• 为运行在 Internet 环境的分布式超媒体系统量身定制• Internet 环境的特点

• 可伸缩性无法控制• 安全性无法控制

• 由一组架构约束来定义• 架构约束：由运行环境加在架构设计之上的约束

#

什么是 REST( 续 )• Web之所以取得成功的技术架构因素总结• REST 是世界上最成功的分布式应用架构风格• 成功案例： Web

• HTTP 1.1 等 Web 标准设计的指导原理• HTTP 1.1就是为实现 REST 风格的架构而设计的• 新的 Web 标准的设计必须符合 REST 的要求，否则整个 Web 的架构会因为引入严重的内在矛盾而崩溃

• 所有的 Web 应用都应该遵守• 不是必须遵守的法律条文，是诱导，而非强迫

#

REST 的架构约束• 客户 - 服务器 (Client-Server)

• 通信只能由客户端单方面发起，表现为请求 /响应的形式• 无状态 (Stateless)

• 通信的会话状态 (Session State) 全部由客户端负责维护• 服务器端负责维护会话状态之外的其他状态，例如资源状态

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

#

REST 的架构约束 ( 续 )• 统一接口 (Uniform Interface)

• 通信的组件之间要有统一的接口，以提高交互的可见性• 分层系统 (Layered System)

• 通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层

• 按需代码 (Code-On-Demand ，可选 )• 通过下载并执行 applet形式或脚本形式的代码，允许对客户端

的功能进行扩展

#

REST 的五个关键词• 资源 (Resource)• 资源的表述 (Representation)• 状态转移 (State Transfer)• 统一接口 (Uniform Interface)• 超文本驱动 (Hypertext Driven)• 又名“将超媒体作为应用状态的引擎” (Hypermedia

As The Engine Of Application State ， HATEOAS)• 超媒体 = 超文本 + 媒体内容

#

什么是资源• 一种看待服务器的方式，将服务器看作是由很多离散的资源组成

• 与 DO 和 RPC 两种架构风格有明显区别• 服务器上一个可命名的抽象概念

• 资源是抽象的概念• 不只能代表服务器上的一个文件、数据库中的一张表等等具体东西• 要多抽象有多抽象，只要想象力允许

• 以名词为核心来组织，首先关注的是名词• 类比：面向对象编程中的接口

• 由一个 URI 来标识• 一个 URI 唯一标识一个资源• 允许多个 URI 标识的资源指向同一数据集

#

什么是资源的表述

• 一段对于资源状态的描述• 可以在客户 - 服务器之间传递• 客户端通过修改资源的表述，并发送到服

务器，来间接修改资源的状态• 资源的表述可以有多种格式• HTML/XML/JSON/ 纯文本

#

什么是状态转移• 将 Web 应用看作是一个由很多状态组成的有限

状态机• 应用状态 ( 即会话状态 ) 由客户端负责维护，

资源状态由服务器端负责维护• 资源之间通过超链接相互关联，超链接代表资

源之间的关系• 从应用的一个状态，转移到应用的下一个状态

#

什么是统一接口• 通过统一的接口来对资源执行各种操作• 对于每个资源只能执行一组有限的操作• HTTP 定义了操作资源的统一接口• 七个标准方法

GET/POST/PUT/DELETE/HEAD/OPTION/TRACE• HTTP 头信息• HTTP 响应状态代码• 操作的语义必须由 HTTP 消息体之前的部分完全表

达

#

什么是超文本驱动• 超媒体不仅仅是数据，还包括了操作的语义• 以超媒体作为引擎，驱动 Web 应用的状态转移• 通过超媒体暴露出服务器所提供的服务• 超媒体定义了服务器所提供的服务的协议• 客户端应该依赖的是超媒体的语义，而不应该对于是否

存在某个 URI 或 URI 的某种特殊构造方式作出假设• 一切都有可能变化，只有超媒体的语义能够长期保持稳

定

#

REST 风格架构的主要特征• 可寻址性 (Addressability)• 无状态性 (Statelessness)• 连通性 (Connectedness)• 统一接口 (Uniform Interface)• 面向资源 (Resource Oriented)• 超文本驱动 (Hypertext Driven)• 松耦合 (Loosely Coupled)

#

REST 风格架构的设计步骤

• 规划数据集• 将数据集划分为资源• 使用 URI 为资源命名• 将资源上的操作映射到 4种 HTTP 方法• 定义表述的媒体格式• 服务器发给客户端的表述• 客户端发给服务器端的表述

#

REST 风格架构的设计步骤(续 )

• 定义资源之间的关系• 用超链接和表单将新的资源与已有资源关

联起来• 根据可能发生的出错情况，定义响应状态

代码

#

REST 与安全性• HTTP Basic/Digest认证• WSSE认证• OpenID• OAuth• HTTPS

#

REST 风格架构带来的好处

• 阳春白雪版• 可伸缩性 (scalability)• 可混搭性 (mashup-ability)• 可用性 (usability)• 可访问性 (accessibility)• 简单性 (simplicity)

#

REST 风格架构带来的好处( 续 )

• 下里巴人版• 简单、规范• 对搜索引擎更友好• 对 Ajax 的支持更好• 可以充分利用浏览器端的缓存• 很容易支持多种类型的客户端

#

关于 HTTP 的一些误解• HTTP 是 RPC 风格的

• 事实： HTTP 其实是 REST 风格的• 统一接口是 REST 与 RPC 的主要区别• REST 风格架构更容易实现大粒度的交互

• HTTP 是一种“传输”协议 (transport protocol)• 被错误翻译为“超文本传输协议”• TCP 才是传输协议，对传输这件工作已经做的很好了• 事实： HTTP 其实是一种“转移”协议 (transfer protocol)

• HTTP 不具备互操作性• 因此需要设计 SOAP 这种“简单”的复杂协议• 事实：充分利用 HTTP ，可以得到比 SOAP 更好的互操作性

#

关于 HTTP 的一些误解 ( 续 )• 浏览器只支持 GET/POST 方法

• HTML 表单仅支持 GET/POST 方法，但是可以通过附加参数( 例如 _method) 的方式模拟 PUT/DELETE 请求

• XMLHttpRequest 支持 GET/POST/PUT/DELETE 4 种方法

#

关于 HTTP 的一些误解 ( 续 )• 误用 HTTP 方法

• GET 方法：安全的、幂等的• PUT/DELETE 方法：不安全的、幂等的• POST 方法：不安全的、不幂等的

• 过度使用 GET 方法• 敏感信息位于 URL 中，不够安全• 容易受到爬虫的伤害

• 过度使用 POST 方法• 例子： SOAP 等 RPC 风格的调用协议• 一个资源承担了过多的职责• 没有充分利用 HTTP 的优点

#

关于 REST 的一些误解• REST 只适用于面向机器的 Web 服务，不适

用于面向人类的 Web 应用• 事实： REST 在 Web 上是普遍适用的

• 直接使用 HTTP 的 API 就是 RESTful API• 事实：在 SOAP 与真正的 RESTful API 之间有广大

的中间地带• REST 不过只是更漂亮的 URI 设计• 事实：这仅仅是 REST 的一个外在特征而已

#

关于 REST 的一些误解 ( 续 )• 统一接口并不重要• 超文本驱动并不重要• 事实：这两个方面是 REST 风格架构的核心

特征，没有这两个特征，可以确定肯定是伪装（挂羊头卖狗肉）的 RESTful API

#

各种编程语言对于 REST 的支持

• Ruby• Ruby on Rails• Sinatra

• PHP• CakePHP

• Python• Django

• Erlang• Yaws

#

各种编程语言对于 REST 的支持( 续 )

• Java• Jersey/RESTEasy/Restlet• Spring MVC 3/Struts 2

• C#• ASP.NET MVC

• JavaScript• jQuery/ExtJS/Dojo/Prototype

• ActionScript• RestfulX

#

REST 与 Web 服务• Web vs. WS-*

• REST 风格的 Web 服务是真正的“ Web 服务”，而不是运行于Intranet环境中的“企业内Web 服务”

• 在 Internet环境中已经完全击败了 DO 风格和 RPC 风格，成为了提供Web 服务的首选

• 两者不是非此即彼的取代关系• REST相关规范

• JAX-RS(Java API for RESTful Web Services ， JSR 311)• WADL(Web Application Description Language)• AtomPub(Atom Publishing Protocol)• OAuth

#

REST 与 SOA• REST 的各种优势在 Intranet 环境中仍

然存在• REST 可以用来暴露服务• REST 可以带来更好的性能和可伸缩性• REST 可以降低开发维护的成本• REST 可以用来实现松耦合• REST 可以用来整合内网和外网的服务

#

REST 不适用的场合• 领域本身就是强事务性的，很难建模为面向资源的

架构• 与松耦合相矛盾• 无法跨越组织的边界• 实现成本高昂

• 对服务的安全性要求非常高• 对服务的结构性要求非常高• 对服务的可组合性要求非常高

• 希望实现与 BPEL 类似的目标

• REST 并不是银弹

#

REST 相关资料• Fielding 博士论文：《架构风格与基于网络的软件架构

设计》• 英文版：

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm• 中文版： http://www.redsaga.com/opendoc/REST_cn.pdf

• RFC 2616(HTTP/1.1)• RFC 2617(HTTP Authentication)• RFC 5023(Atom Publishing Protocol)• RFC 5849(OAuth)

#

REST 相关资料 ( 续 )• WADL

• http://www.w3.org/Submission/wadl/• JAX-RS(JSR 311)

• http://jcp.org/en/jsr/detail?id=311• REST and JSR 311

• http://www.innoq.com/blog/st/presentations/2008/2008-11-03-JSR311--JUGCGN.pdf

#

REST 相关资料 ( 续 )• 深入浅出 REST

• http://www.infoq.com/cn/articles/rest-introduction• 解答关于 REST 的 10 点疑惑

• http://www.infoq.com/cn/articles/tilkov-rest-doubts• 面向资源的架构： REST 的另一面

• http://www.infoq.com/cn/articles/roa-rest-of-rest

#

REST 相关图书• 《 RESTful Web Services 中文版》• 《 RESTful Web Services

Cookbook 》• 《 REST in Practice 》

#

Q & A

#

最后的唠叨• 浏览器是最符合 REST 要求的 Web 应用• 在设计分布式应用的架构时，请想想浏览

器是如何工作的• 无论开发 Web 应用还是 Web 服务，模仿

浏览器的工作方式都是值得推荐的做法• 拥抱 Web 的架构风格，融入 Web ，成为

Web 的一部分 !

#

感谢您的聆听• 我的联系方式：• email: dlee.cn@gmail.com• gtalk: dlee.cn@gmail.com• 阿里旺旺： dleecn