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