• 1. REST、超媒体与Web API 拥抱Web原生的架构设计原则主讲人:李锟
  • 2. 什么是REST?
  • 3. 什么是REST?全称Representational State Transfer(表述性状态移交) 由Roy Fielding在其2000年的博士论文Architectural Styles and the Design of Network-based Software Architectures(架构风格与基于网络应用软件的架构设计)中提出 有两种理解方式 REST是一种抽象的架构风格(architectural style) REST是一种为 面向互联网的应用软件 量身定制的架构风格 REST是Web自身的架构风格,是Web取得巨大成功在技术层面的原因和理论基础 REST在Web上是普适的,同时适用于Web应用和Web API REST是一种分布式应用的架构设计方法
  • 4. API的分类进程内调用API 调用本地开发库 本地进程间调用API Linux IPC Android IPC 远程调用API 内网API——企业内网中的API 外网API——面向互联网的API 外网应用内部API 外网公共API
  • 5. 什么是RESTful API?符合REST架构风格要求的API 通常基于HTTP实现 将HTTP作为一种应用协议,而不是作为传输协议来使用 Fielding在其博士论文的第6章中,明确指出“HTTP不是一种传输协议” SOAP将HTTP作为传输协议来使用,是一种非常低效的用法 将HTTP翻译为“超文本传输协议”是中国技术翻译史上的一大误译 REST APIs must be hypertext-driven ! 又称作“使用超媒体作为应用状态的引擎”( HATEOAS)
  • 6. Richardson成熟度模型
  • 7. Richardson成熟度模型第0级:没有明确的资源概念,只有一个URL,只使用单个HTTP方法 第1级:有明确的资源概念,存在很多URL,只使用单个HTTP方法 第2级:有明确的资源概念,存在很多URL,使用HTTP作为操作资源的统一接口 通常将对于资源的CRUD式操作分别映射到4个HTTP方法 第3级:在满足第2级标准的基础上,使用超媒体作为应用状态的引擎(HATEOAS)
  • 8. 什么是Web API?
  • 9. 什么是Web API?一种新式的API类型,通常面向互联网 主要用来实现外网公共API & 外网应用内部API 在一些场合也可以用来实现内网API 与传统的Web Services完全不同 一种新式的API设计方法 最大限度利用HTTP协议 将HTTP协议当作应用协议,而不是传输协议来使用 使用HTTP协议作为操作资源的统一接口 可以透明升级到HTTP/2 使用超媒体作为应用状态的引擎(HATEOAS) RESTful API的高级形式
  • 10. Web API是最高等级的RESTful API完全实现了REST架构风格的四个价值主张 可伸缩性 安全性 松耦合 简单性 主要是针对客户端应用开发者 可以统一不同种类API的设计风格,降低了客户端应用开发者的学习和开发成本 拥抱Web原生的架构设计原则 拥抱REST 拥抱超媒体 接受失控,而不是企图控制一切,坦然接受不完美
  • 11. RESTful API只达到第2级有什么问题?仍然是紧耦合的 依赖固定的URL结构 依赖固定的调用方式 依赖服务描述文档 难以做较大改动 交互的粒度仍然很小 CRUD式服务仅仅适用于简单的业务建模 难以实现复杂的业务操作协议 不得不将版本号加入到URL以解决升级问题 导致了API数量的膨胀
  • 12. HATEOAS是否是值得追求的?优势 解决了RESTful API仅仅达到第2级存在的所有问题 实现了REST架构风格的所有价值主张 劣势 对于服务器端应用开发人员而言,设计较为复杂 在API设计上多花一些时间,在维护上少花很多时间 在API设计上少花一些时间,在维护上多花很多时间 是否值得,主要取决于对松耦合、大粒度交互的需求强度,可开展ROI分析
  • 13. 设计良好的Web API很像是一个网站
  • 14. Web API与Web应用的类比都使用HTTP协议来与服务器交互 都使用超媒体作为资源表述的格式 Web应用使用面向人类的超媒体——HTML,资源的表述对应Web页面 Web API使用面向机器的超媒体——AtomPub、Odata、 HAL、Collection+JSON、Hydra …… 资源的表述对应HTTP响应的body 都需要理解超文本的语义 Web应用依靠人类阅读超文本的描述文字来理解其语义 Web API依靠机器解析超文本的语义标记来理解其语义 资源的表述之间都应该通过超文本相互链接起来 不应该出现完全孤立的资源表述
  • 15. Web API中两种不同范畴的语义协议语义:protocol affordances 使用HTTP协议如何与超媒体控件交互 应该包括在媒体类型中,例如Hydra 无需编写人类可读的文档 并非特定于某个业务领域 可以开发通用的客户端库和测试工具来处理 应用语义:application affordances 某个超媒体控件的含义是什么,与其交互可以得到什么结果 需要编写人类可读的文档,又名profile 特定于某个业务领域
  • 16. 应用语义与词汇表应用语义是由人类可读的profile文档来描述 首先应保证人类可读,机器可读不是必须的 应用语义的基本组成元素——语义描述符 词汇表是语义描述符的汇总 常用的词汇表 schema.org:http://schema.org/ GoodRelations:http://www.heppnetz.de/ontologies/goodrelations/v1 应尽量选择使用常用词汇表中定义的通用语义描述符:例如在线购物、在线图片库、微博等等
  • 17. 什么是Hydra?
  • 18. 什么是Hydra?全名Hypermedia-Driven Web APIs 一套规范和相关的技术,用来简化设计开发支持HATEOAS的Web API Hydra Core Vocabulary规范:http://www.hydra-cg.com/spec/latest/core/ 一种面向Web API设计的超媒体格式 负责人Markus Lanthaler(谷歌) 有可能会成为正式的Web标准 基于JSON-LD(A JSON-based Serialization for Linked Data), JSON-LD已经是正式的Web标准 Hydra相关资源汇总:http://www.hydra-cg.com
  • 19. Spring HATEOAS介绍http://projects.spring.io/spring-hateoas/ https://github.com/garmin/spring-hateoas 基于Spring MVC的开发库,支持在生成的表述中加入超文本 可支持多种媒体类型 HAL:基于JSON或XML格式 只适用于开发只读类Web API Hydra:基于JSON格式 适用于开发各种Web API
  • 20. 可参考的开源项目hydra-java:https://github.com/dschulten/hydra-java 支持Hydra的Java库 包括Spring HATEOAS的扩展,为Spring HATEOAS增加了对于Hydra的支持 支持建造使用Hydra作为资源表述格式的更加强大的Web API 默认输出Hydra格式的超媒体,也可输出XHTML格式的超媒体 hydra-sample:使用Hydra的Web API例子 hydra-core:https://github.com/bergos/hydra-core 支持Hydra的客户端JS库,可用于访问使用Hydra的Web API
  • 21. Web API设计步骤Amundsen七步设计法 1. 罗列语义描述符 2. 画应用状态图 3. 调整命名 4. 选择一种媒体类型 5. 编写profile 6. 实现 7. 发布
  • 22. Web API设计步骤简化过的五步设计法 1. 罗列语义描述符 2. 画应用状态图 3. 调整命名 4. 实现(基于Hydra) 5. 发布
  • 23. 画应用状态图的例子
  • 24. Web API中的可变与不可变可变 可以删除已发布的某个资源 可以修改资源的URL 可以改变资源上可执行的操作(GET/POST/PUT/DELETE) 可以改变资源表述的内容 不可变 已经发布的应用语义和语义描述符应长期保持不变(向后兼容)
  • 25. Web API设计最佳实践分离协议语义和应用语义 认真画好应用状态图 方框:资源的表述 连接线:一次应用状态迁移(一次HTTP调用) 连接线上的文字:语义描述符 优先使用通用的语义 schema.org GoodRelations 基于某种超媒体类型(例如Hydra)开发通用的客户端库
  • 26. Web API能解决的问题松耦合 不依赖固定的URL结构 不依赖固定的调用方式 易于改动和升级 统一的设计风格 降低了客户端应用开发人员的学习成本 易于实现通用的客户端库 支持更大粒度的交互 开发人员不容易混淆远程调用与本地调用 会改善用户可感知的性能
  • 27. Web API能解决的问题支持数据流和管道 易于实现分层的缓存,提高了服务器端应用的可伸缩性 最好的互操作性 基于HTTP协议,几乎所有编程语言都支持 易于跨越组织的边界实现API的集成
  • 28. Web API不能解决的问题不支持有状态的长连接,无法进行双向通信,实时性较差 让服务器端应用开发人员早点下班 把轻松留给客户端应用开发人员,把困难留给自己——佛祖 把困难留给客户端应用开发人员,把轻松留给自己——人渣 设计开发领域模型 DDD是设计开发领域模型的利器 DDD与Web API是互补的关系,可相互支持
  • 29. Web API服务器端开发人员的利益可以自由添加新的资源表述(联想到为网站添加新的页面),并且把新增资源表述与已有资源表述链接起来,即:定义新的应用状态迁移(资源链接的语义描述符)。 可以改变某个已有资源的URL地址。 可以为某个已有应用状态迁移(一次HTTP请求)添加新的请求参数。新增参数不是必需的。 可以为某个已有应用状态迁移(一次HTTP请求)删除不是必需的请求参数。 可以为某个已有应用状态迁移(一次HTTP请求)添加新的响应参数。新增参数不是必需的。 可以为某个已有应用状态迁移(一次HTTP请求)删除不是必需的响应参数。 可以充分利用各级别的HTTP缓存,改善可伸缩性。
  • 30. Web API客户端开发人员的利益只需要理解应用的语义(定义在profile文档中),不需要假设某个资源一定存在,URL一定是某种格式。 除了入口URL,不再依赖服务器端的固定URL,不必再自己构造URL。 可以开发理解HTTP协议语义的通用库来简化客户端开发。 提高了健壮性,当服务器端API升级时,只要已经发布的应用语义和应用状态迁移保持不变,客户端应用就不会崩溃。 可以自由探索服务器端新增的功能(应用状态迁移),根据服务器端新增功能加强客户端功能。 可以实现更大粒度的交互。 可以基于统一的风格来调用服务器端API,降低了学习和开发成本。
  • 31. 未来的展望Hydra Core Vocabulary成为正式的Web标准 出现更多针对特定领域的词汇表 基于Hydra开发通用的客户端库 支持Hydra的自动化测试工具 Web API与微服务的结合 Web API与DDD的结合
  • 32. Web API名人堂Tim Berners-LeeRoy T. FieldingStefan Tilkov
  • 33. Web API名人堂Jim WebberMike AmundsenMarkus Lanthaler
  • 34. 参考图书资料《REST实战》,Jim Webber, Savas Parastatidis, Ian Robinson合著 《RESTful WebServices Cookbook中文版》,Subbu Allamaraju 著 《RESTful Web APIs中文版》,Leonard Richardson, Mike Amundsen合著 《RESTful Web Clients中文版》(今年下半年即将出版),Mike Amundsen著 《失控》,凯文·凯利 著 《架构风格与基于网络应用软件的架构设计》,Roy Fielding博士论文中文版 《架构风格与基于网络应用软件的架构设计》导读 理解本真的REST架构风格 Hydra相关资源汇总:http://www.hydra-cg.com
  • 35. 结束语拥抱Web原生的架构设计原则! 在API设计中尝试使用超媒体,从使用Hydra开始!
  • 36. 感谢您的聆听!我的联系方式: 邮箱:dlee.cn@gmail.com “REST实战讨论组”QQ群:81207617