• 1. 内网API设计风格对比分析选择最适合业务需要的API设计风格 主讲人:李锟
  • 2. API的分类进程内调用API 调用本地开发库 本地进程间调用API Linux IPC Android IPC 远程调用API 内网API——企业内网中的API 外网API——面向互联网的API 外网应用内部API 外网公共API
  • 3. 什么是架构风格?一种 架构风格 是由一组相互协作的 架构约束 来定义的。架构约束是指应用软件的运行环境对于架构设计的约束条件。 应用软件的架构设计不能脱离其运行环境。 不同的运行环境,决定了应用的类型。不同类型的应用,会有不同的架构风格。 架构风格比 架构实例(具体的架构)更加抽象。架构风格与架构实例可以理解为类似于OOP中接口与实现类之间的关系。 架构风格是从建筑学中借用来的概念。 来自美国建筑大师Christopher Alexander名著《建筑的永恒之道》(The Timeless Way of Building) 建筑学中的不同风格流派举例:山西平遥乔家大院、安徽歙县徽商大宅院、江苏苏州拙政园
  • 4. 分布式应用的架构风格服务设计、服务粒度划分 面向服务的架构(Service Oriented Architecture,简称SOA) 微服务架构(Microservices Architecture) 领域驱动设计(Domain-Driven Design,简称DDD)
  • 5. 分布式应用的架构风格远程调用API 分布式对象(Distributed Objects,简称DO) CORBA/RMI/EJB/DCOM/.NET Remoting 远程过程调用(Remote Procedure Call,简称RPC) SOAP/XML-RPC/JSON-RPC/Hessian/Burlap/Flash AMF/Dubbo RPC 基于Google Protocol Buffer数据交换格式的各种RPC协议 基于Apache Thrift的各种RPC协议,例如唯品会的OSP 表述性状态移交(Representational State Transfer,简称REST) 将HTTP协议真正作为一种 应用协议 来使用,不再需要基于HTTP的各种RPC协议 RESTful API——符合REST架构风格要求的API
  • 6. 什么是REST?
  • 7. 什么是REST?由Roy Fielding在其2000年的博士论文《架构风格与基于网络应用软件的架构设计》(Architectural Styles and the Design of Network-based Software Architectures)中提出 REST有两种理解方式 REST是一种分布式应用的架构风格——抽象层面 REST是一种为 面向互联网的应用软件 量身定制的架构风格 REST正是 Web自身的架构风格,它是Web所取得的巨大成功在技术层面的原因和理论基础 REST在Web之上是 普适的,同时适用于Web App和Web API REST是一种分布式应用的架构设计方法——具体层面 REST有很多具体的设计原则和指导,实战性很强
  • 8. REST与RPC两种API调用风格的区别REST对服务器端做抽象的基本单元是 资源,RPC对服务器端做基本抽象的单元是 过程。REST的建模是以名词为核心的,RPC的建模是以动词为核心的。 RPC中没有统一接口的概念。即使采用相同的协议,不同的API,设计风格可以完全不同。RPC也不支持操作语义对于中间组件的可见性。 RPC中无法使用超媒体,响应的内容只包含数据。REST中使用了超媒体后,可以实现很大粒度的交互,交互的效率比RPC更高。 REST支持数据流和管道,RPC不支持数据流和管道。 因为使用了平台中立的消息,RPC的耦合度会比DO要小一些,但是RPC也常常会带来客户端与服务器端的紧耦合。REST中假如使用了超媒体,客户端与服务器端可以达到最小的耦合度。
  • 9. RPC API的优点对于服务器端开发人员而言,容易设计、开发 便于做集中的监控 基于socket的二进制RPC协议,建立连接延迟低、网络传输效率高 支持有状态的长连接,可进行双向通信,实时性好
  • 10. RPC API的缺点紧耦合 API一旦暴露出去,就难以再做改动 没有统一的设计风格 增加了客户端开发人员的学习成本 难以实现通用的客户端库 通常粒度较小 开发人员很容易混淆远程调用与本地调用 会损害用户(客户端)可感知的性能
  • 11. Richardson成熟度模型
  • 12. Richardson成熟度模型第0级:没有明确的资源概念,只有一个URL,只使用单个HTTP方法。 第1级:有明确的资源概念,存在很多URL,只使用单个HTTP方法。 第2级:有明确的资源概念,有很多URL,使用HTTP作为操作资源的统一接口。 通常将对于资源的CRUD式操作分别映射到4个HTTP方法。 第3级:在第2级的基础上,使用超媒体作为应用状态的引擎(Hypermedia as the Engine of Application State,简称HATEOAS)。
  • 13. 内网API暂时不需要支持HATEOAS内网API运行在一个可控的环境中 运行在同一个组织的边界之内 服务器端开发团队和客户端开发团队可以密切沟通 运行环境相对安全,基本上不会出现恶意的请求 内网API需要做服务治理 支持HATEOAS的RESTful API不便于做服务治理 支持HATEOAS相关的生态环境还不够成熟 通用的媒体类型尚未完全标准化,例如Hydra Core 开发框架、开发库尚不成熟 缺少自动化测试工具
  • 14. 第2级RESTful API能解决的问题更加松耦合 改动RESTful API比改动RPC API更容易 更好的可伸缩性 与基于HTTP的各种RPC协议相比,对HTTP的使用更有效率 便于利用HTTP缓存 支持数据流和管道 易于实现分层的缓存,提高了服务器端应用的可伸缩性 有统一的设计和编程风格 服务器端 客户端
  • 15. 第2级RESTful API能解决的问题测试更容易,可以使用各种HTTP测试工具 Postman/ Advanced REST Client curl/wget SoapUI Pro Jmeter ab/httperf/curl-loader 浏览器 最好的互操作性 基于HTTP协议本身,几乎所有编程语言都能支持
  • 16. 第2级RESTful API不能解决的问题不支持有状态的长连接,无法进行双向通信,实时性较差 让服务器端应用开发人员早点下班 把轻松留给客户端应用开发人员,把困难留给自己——佛祖 把困难留给客户端应用开发人员,把轻松留给自己——人渣 设计开发领域模型 DDD是设计开发领域模型的利器 DDD与REST是互补的关系,可相互支持
  • 17. 在RPC和REST两种风格之间如何做取舍根据服务所实现的业务逻辑变化的频繁程度 业务逻辑变化频繁,必须实现松耦合:选择REST 业务逻辑固定,变化非常少,可以接受紧耦合:选择RPC 根据对于延迟、网络传输效率、实时性的要求 必须确保低延迟、网络传输效率高、实时性:选择RPC 对延迟、网络传输效率、实时性要求不高:选择REST 根据对可伸缩性的要求 对可伸缩性要求非常高:选择REST 对可伸缩性要求不高:选择RPC
  • 18. 对于HTTP的常见误解浏览器只支持GET/POST方法 HTML表单仅支持GET/POST方法,但是可以通过附加参数(例如_method)的方式模拟PUT/DELETE请求 XMLHttpRequest对象GET/POST/PUT/DELETE 4种方法均可支持 未遵循HTTP协议的指导误用HTTP方法 GET方法:安全的、幂等的 POST方法:不安全的、不幂等的 PUT/DELETE方法:不安全的、幂等的
  • 19. 对于HTTP的常见误解过度使用GET方法 敏感信息位于URL中,不够安全 容易受到爬虫的伤害 过度使用POST方法 例子:SOAP等RPC风格的调用协议 一个方法承担了过多职责 没有充分利用HTTP的优势
  • 20. 对于HTTP的常见误解HTTP是一种RPC风格的协议 事实:HTTP其实是一种REST风格的协议 统一接口是REST与RPC两种风格协议的主要区别 HTTP是一种“传输”协议(transport protocol) 被错误翻译为“超文本传输协议” 事实:HTTP其实是一种“移交”协议(transfer protocol)。TCP才是传输协议,对传输这件工作已经做的很好了。 传输协议和移交协议的区别 传输协议做的是底层搬运比特之类的苦力活,不包含操作的语义 移交协议做的事情比传输协议更高级,包含了操作的语义
  • 21. 对于HTTP的常见误解HTTP不具备互操作性 因此需要在HTTP之上设计SOAP这种“简单”的协议(事实上很复杂) 事实:充分利用好HTTP,已经能够得到足够好的互操作性,在很多场合甚至比使用SOAP更好
  • 22. 对于REST的常见误解REST只适用于面向机器的Web API,不适用于面向人类的Web App 事实:REST在Web上是普遍适用的 直接使用HTTP的API就是RESTful API 事实:在SOAP与真正的RESTful API之间还有广大的中间地带 只达到Richardson成熟度模型第0级的API不是RESTful API REST只不过是更漂亮的URI设计 事实:这仅仅是REST的一个外在特征而已
  • 23. 对于REST的常见误解统一接口并不重要 HATEOAS并不重要 事实:这两个方面都是REST架构风格的核心特征 至少需要实现统一接口,否则可以确定是冒牌的RESTful API 统一接口只能使用HTTP实现 事实:HTTP仅仅是实现REST架构风格的一种方式 其他符合REST统一接口的例子:扩展了HTTP协议的WebDAV协议
  • 24. 支持第2级RESTful API开发的Java开发框架不支持JAX-RS规范的开发框架 Spring MVC Struts 支持JAX-RS规范的开发框架 Jersey RESTEasy Restlet Apache CXF
  • 25. 内网RESTful API要解决的现实问题性能:延迟、网络传输效率 大多数情况下,建立连接所消耗的时间,与服务业务逻辑的IO操作相比非常小 可升级到HTTP/2,HTTP/2极大改善了HTTP/1.1的性能 服务治理 服务注册、服务发现 自动负载均衡 流量控制 服务质量 版本化 可在URL中加版本号
  • 26. 参考图书资料《REST实战》 《RESTful WebServices Cookbook中文版》 《Java RESTful Web Service实战》 《微服务设计》 《领域驱动设计:软件核心复杂性应对之道》 《架构风格与基于网络应用软件的架构设计》 《架构风格与基于网络应用软件的架构设计》导读 理解本真的REST架构风格
  • 27. 结束语理解内网不同API设计风格的优缺点。 根据业务需要选择最适合的API设计风格。
  • 28. 感谢您的聆听!我的联系方式: 邮箱:dlee.cn@gmail.com “REST实战讨论组”QQ群:81207617