Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rest与面向资源的web开发

3,460 views

Published on

REST与面向资源的Web开发, 包括起源,概念和一些应用介绍。

Published in: Technology
  • Be the first to comment

Rest与面向资源的web开发

  1. 1. REST 与面向资源的 Web 开发深入理解 Web 的架构风 格 主讲人:李锟 (dlee)
  2. 2. # 我是谁 • 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 的平台技术部
  3. 3. # 讲座内容 • 什么是 Web • 什么是 REST • REST 的架构约束 • REST 的五个关键词 • REST 风格架构的主要特 征 • REST 风格架构的设计步 骤 • REST 与安全性 • REST 风格架构带来的好 处 • 关于 HTTP 的一些误解 • 关于 REST 的一些误解 • 各种编程语言对于 REST 的支持 • REST 与 Web 服务 • REST 与 SOA • REST 不适用的场合
  4. 4. # 什么是 Web • World Wide Web( 万维网 ) ,简称 WWW 或 Web • 浏览器? HTML ? Ajax ? Flash ? Web 2.0 ? • Web 的三大技术基石 • URI :用来标识资源 • HTTP :用来操作资源 • Hypertext :用来描述资源的状态 • HTML • XML • JSON/ 纯文本
  5. 5. # 什么是 Web( 续 ) • 定义“ Web 应用” • 使用了上述三大技术 • 运行在 Internet 环境中 • 与“企业应用”相对 • 广义的 Web 应用 • 包括所有使用了上述三大技术的应用 • 狭义的 Web 应用 • 仅包括运行于浏览器中的应用 • 与“桌面应用”相对 • Web 已死?
  6. 6. # 什么是 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 实战”讨论组中有这篇论文的导读
  7. 7. # 什么是 REST( 续 ) • Web 自身的架构风格 (Architectural Style) • 架构风格的概念来自建筑学,比架构更为抽象 • 例子:分布式对象( DO )、远程过程调用( RPC ) • 类比:接口 - 实现 或 类 - 实例 • 为运行在 Internet 环境的分布式超媒体系统量身定制 • Internet 环境的特点 • 可伸缩性无法控制 • 安全性无法控制 • 由一组架构约束来定义 • 架构约束:由运行环境加在架构设计之上的约束
  8. 8. # 什么是 REST( 续 ) • Web 之所以取得成功的技术架构因素总结 • REST 是世界上最成功的分布式应用架构风格 • 成功案例: Web • HTTP 1.1 等 Web 标准设计的指导原理 • HTTP 1.1 就是为实现 REST 风格的架构而设计的 • 新的 Web 标准的设计必须符合 REST 的要求,否则 整个 Web 的架构会因为引入严重的内在矛盾而崩溃 • 所有的 Web 应用都应该遵守 • 不是必须遵守的法律条文,是诱导,而非强迫
  9. 9. # REST 的架构约束 • 客户 - 服务器 (Client-Server) • 通信只能由客户端单方面发起,表现为请求 / 响应的形式 • 无状态 (Stateless) • 通信的会话状态 (Session State) 全部由客户端负责维护 • 服务器端负责维护会话状态之外的其他状态,例如资源状态 • 缓存 (Cache) • 响应内容可以在通信链条的某处被缓存,以改善网络效率
  10. 10. # REST 的架构约束 ( 续 ) • 统一接口 (Uniform Interface) • 通信的组件之间要有统一的接口,以提高交互的可见性 • 分层系统 (Layered System) • 通过限制组件的行为(即,每个组件只能“看到”与其交互的紧 邻层),将架构分解为若干等级的层 • 按需代码 (Code-On-Demand ,可选 ) • 通过下载并执行 applet 形式或脚本形式的代码,允许对客户端 的功能进行扩展
  11. 11. # REST 的五个关键词 • 资源 (Resource) • 资源的表述 (Representation) • 状态转移 (State Transfer) • 统一接口 (Uniform Interface) • 超文本驱动 (Hypertext Driven) • 又名“将超媒体作为应用状态的引擎” (Hypermedia As The Engine Of Application State , HATEOAS) • 超媒体 = 超文本 + 媒体内容
  12. 12. # 什么是资源 • 一种看待服务器的方式,将服务器看作是由很多离散的资源组成 • 与 DO 和 RPC 两种架构风格有明显区别 • 服务器上一个可命名的抽象概念 • 资源是抽象的概念 • 不只能代表服务器上的一个文件、数据库中的一张表等等具体东西 • 要多抽象有多抽象,只要想象力允许 • 以名词为核心来组织,首先关注的是名词 • 类比:面向对象编程中的接口 • 由一个 URI 来标识 • 一个 URI 唯一标识一个资源 • 允许多个 URI 标识的资源指向同一数据集
  13. 13. # 什么是资源的表述 • 一段对于资源状态的描述 • 可以在客户 - 服务器之间传递 • 客户端通过修改资源的表述,并发送到服 务器,来间接修改资源的状态 • 资源的表述可以有多种格式 • HTML/XML/JSON/ 纯文本
  14. 14. # 什么是状态转移 • 将 Web 应用看作是一个由很多状态组成的有限 状态机 • 应用状态 ( 即会话状态 ) 由客户端负责维护, 资源状态由服务器端负责维护 • 资源之间通过超链接相互关联,超链接代表资 源之间的关系 • 从应用的一个状态,转移到应用的下一个状态
  15. 15. # 什么是统一接口 • 通过统一的接口来对资源执行各种操作 • 对于每个资源只能执行一组有限的操作 • HTTP 定义了操作资源的统一接口 • 七个标准方法 GET/POST/PUT/DELETE/HEAD/OPTION/TRACE • HTTP 头信息 • HTTP 响应状态代码 • 操作的语义必须由 HTTP 消息体之前的部分完全表 达
  16. 16. # 什么是超文本驱动 • 超媒体不仅仅是数据,还包括了操作的语义 • 以超媒体作为引擎,驱动 Web 应用的状态转移 • 通过超媒体暴露出服务器所提供的服务 • 超媒体定义了服务器所提供的服务的协议 • 客户端应该依赖的是超媒体的语义,而不应该对于是否 存在某个 URI 或 URI 的某种特殊构造方式作出假设 • 一切都有可能变化,只有超媒体的语义能够长期保持稳 定
  17. 17. # REST 风格架构的主要特征 • 可寻址性 (Addressability) • 无状态性 (Statelessness) • 连通性 (Connectedness) • 统一接口 (Uniform Interface) • 面向资源 (Resource Oriented) • 超文本驱动 (Hypertext Driven) • 松耦合 (Loosely Coupled)
  18. 18. # REST 风格架构的设计步骤 • 规划数据集 • 将数据集划分为资源 • 使用 URI 为资源命名 • 将资源上的操作映射到 4 种 HTTP 方法 • 定义表述的媒体格式 • 服务器发给客户端的表述 • 客户端发给服务器端的表述
  19. 19. # REST 风格架构的设计步骤 ( 续 ) • 定义资源之间的关系 • 用超链接和表单将新的资源与已有资源关 联起来 • 根据可能发生的出错情况,定义响应状态 代码
  20. 20. # REST 与安全性 • HTTP Basic/Digest 认证 • WSSE 认证 • OpenID • OAuth • HTTPS
  21. 21. # REST 风格架构带来的好处 • 阳春白雪版 • 可伸缩性 (scalability) • 可混搭性 (mashup-ability) • 可用性 (usability) • 可访问性 (accessibility) • 简单性 (simplicity)
  22. 22. # REST 风格架构带来的好处 ( 续 ) • 下里巴人版 • 简单、规范 • 对搜索引擎更友好 • 对 Ajax 的支持更好 • 可以充分利用浏览器端的缓存 • 很容易支持多种类型的客户端
  23. 23. # 关于 HTTP 的一些误解 • HTTP 是 RPC 风格的 • 事实: HTTP 其实是 REST 风格的 • 统一接口是 REST 与 RPC 的主要区别 • REST 风格架构更容易实现大粒度的交互 • HTTP 是一种“传输”协议 (transport protocol) • 被错误翻译为“超文本传输协议” • TCP 才是传输协议,对传输这件工作已经做的很好了 • 事实: HTTP 其实是一种“转移”协议 (transfer protocol) • HTTP 不具备互操作性 • 因此需要设计 SOAP 这种“简单”的复杂协议 • 事实:充分利用 HTTP ,可以得到比 SOAP 更好的互操作性
  24. 24. # 关于 HTTP 的一些误解 ( 续 ) • 浏览器只支持 GET/POST 方法 • HTML 表单仅支持 GET/POST 方法,但是可以通过附加参数 ( 例如 _method) 的方式模拟 PUT/DELETE 请求 • XMLHttpRequest 支持 GET/POST/PUT/DELETE 4 种方法
  25. 25. # 关于 HTTP 的一些误解 ( 续 ) • 误用 HTTP 方法 • GET 方法:安全的、幂等的 • PUT/DELETE 方法:不安全的、幂等的 • POST 方法:不安全的、不幂等的 • 过度使用 GET 方法 • 敏感信息位于 URL 中,不够安全 • 容易受到爬虫的伤害 • 过度使用 POST 方法 • 例子: SOAP 等 RPC 风格的调用协议 • 一个资源承担了过多的职责 • 没有充分利用 HTTP 的优点
  26. 26. # 关于 REST 的一些误解 • REST 只适用于面向机器的 Web 服务,不适 用于面向人类的 Web 应用 • 事实: REST 在 Web 上是普遍适用的 • 直接使用 HTTP 的 API 就是 RESTful API • 事实:在 SOAP 与真正的 RESTful API 之间有广大 的中间地带 • REST 不过只是更漂亮的 URI 设计 • 事实:这仅仅是 REST 的一个外在特征而已
  27. 27. # 关于 REST 的一些误解 ( 续 ) • 统一接口并不重要 • 超文本驱动并不重要 • 事实:这两个方面是 REST 风格架构的核心 特征,没有这两个特征,可以确定肯定是伪 装(挂羊头卖狗肉)的 RESTful API
  28. 28. # 各种编程语言对于 REST 的支 持 • Ruby • Ruby on Rails • Sinatra • PHP • CakePHP • Python • Django • Erlang • Yaws
  29. 29. # 各种编程语言对于 REST 的支持 ( 续 ) • Java • Jersey/RESTEasy/Restlet • Spring MVC 3/Struts 2 • C# • ASP.NET MVC • JavaScript • jQuery/ExtJS/Dojo/Prototype • ActionScript • RestfulX
  30. 30. # 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
  31. 31. # REST 与 SOA • REST 的各种优势在 Intranet 环境中仍 然存在 • REST 可以用来暴露服务 • REST 可以带来更好的性能和可伸缩性 • REST 可以降低开发维护的成本 • REST 可以用来实现松耦合 • REST 可以用来整合内网和外网的服务
  32. 32. # REST 不适用的场合 • 领域本身就是强事务性的,很难建模为面向资源的 架构 • 与松耦合相矛盾 • 无法跨越组织的边界 • 实现成本高昂 • 对服务的安全性要求非常高 • 对服务的结构性要求非常高 • 对服务的可组合性要求非常高 • 希望实现与 BPEL 类似的目标 • REST 并不是银弹
  33. 33. # 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)
  34. 34. # 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
  35. 35. # 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
  36. 36. # REST 相关图书 • 《 RESTful Web Services 中文版》 • 《 RESTful Web Services Cookbook 》 • 《 REST in Practice 》
  37. 37. # Q & A
  38. 38. # 最后的唠叨 • 浏览器是最符合 REST 要求的 Web 应用 • 在设计分布式应用的架构时,请想想浏览 器是如何工作的 • 无论开发 Web 应用还是 Web 服务,模仿 浏览器的工作方式都是值得推荐的做法 • 拥抱 Web 的架构风格,融入 Web ,成为 Web 的一部分 !
  39. 39. # 感谢您的聆听 • 我的联系方式: • email: dlee.cn@gmail.com • gtalk: dlee.cn@gmail.com • 阿里旺旺: dleecn

×