Rest Notes-表述性状态移交(Representational State Transfer ,REST)

摘要: 上篇文章提到的“新的架构风格(REST)”就是专门为分布式超媒体系统设计的,它由几种基于网络的架构风格中衍生而来的一种混合架构风格,并且添加了一些额外的架构约束,用来定义统一的连接器接口

正文:

推导REST

Web架构背后的设计基础理论可以描述为由一组应用于架构中元素之上的架构约束组成的架构风格

从“空”风格(Null Style)开始

无论是建筑还是软件,架构过程有着两种常见的观点:

  1. 设计者一切从0开始最后建造出一个架构,直到架构满足系统需求
  2. 设计者从一个整体的系统需求出发,此时没有任何约束(空风格),通过增量的识别出各种约束应用于系统的架构元素之上,不了解架构元素的可以回看第一篇文章

REST正是使用第二种观点开发出来的,从架构的观点来看,空风格描述了一个组件之间没有明显边界的系统,这就是我们描述REST的起点

null style

客户-服务器

首先添加一个客户-服务器约束,该约束背后原则是分离关注点,通过分离用户界面和数据存储这两个关注点,提高了可移植性可伸缩性。对于Web而言最重要的是这种关注点分离使得组件可以独立的部署与进化

cs

无状态

接下来添加一个无状态约束:通信必须在本质上是无状态的,从客户端到服务器的每个请求都必须包含理解该请求所必需的所有信息,会话状态要全部保存在客户端

这一约束产生了可见性可靠性可伸缩性三个架构属性,原因可以去查看上面无状态的超链接,这里不重复解释

css

缓存.

为了改善网络的效率,我们添加了缓存这个架构约束,好处在于减少了一些交互,从而提高效率和用户感知性能

ccss

早期的Web架构(1994年之前)是通过客户-缓存-无状态-服务器的架构约束集合(风格)来定义的,交互的通信协议仅包含了对非共享缓存(non-shared caches)的支持,并没有限定接口要对所有的资源提供一组一致的语义。相反地,Web依赖于使用一个公共的客户-服务器实现库(CERN的libwww)来维护Web应用之间的一致性

早期Web架构

由于Web实现的开发者们早已超越了这种早期的设计,请求除了静态的文档之外还能够识别出动态生成的响应,也以代理和共享缓存的形式开展了对中间件的开发工作,但是必须对现有的协议进行扩展,这样中间件才能可靠的通信。以下三个架构约束(统一接口,分层系统,按需代码)则是对早期Web架构的扩充,以便用来对现代的Web架构的扩展加以指导

统一接口

本约束也是使得REST风格与别的风格产生区别的核心特征,通过在组件接口上应用通用性的软件工程原则来简化系统架构,也改善了交互的可见性,也使得它们提供的服务与实现是解耦的,促进了独立的可进化性。当然任何东西都有两面性,统一接口的代价就是降低了效率。因为信息都是使用标准的形式来移交的,而不是特定于应用需求的形式。

统一接口的意义在于凡是参与到每一个http通信的所有组件(浏览器、http代理、服务网关、web服务器、应用服务器等),都可以理解这个请求。构成这个请求的是uri、http、mime、html,用url标识资源,用http操作资源的表述,用mime协商请求双方都接收的媒体类型(html、json、xml等)

REST接口被设计为可以高效的移交大粒度的超媒体数据,并对Web的场景情况做了优化,但是这也导致该接口对于其他形式的架构交互而言并不是最优的

uccss

为了获得统一接口,需要多个架构约束来指导组件的行为,REST由四个接口架构约束来定义:

  • 资源的识别
  • 通过表述来操作资源
  • 自描述的信息
  • 超媒体作为应用程序状态的引擎(HATEOAS)

分层系统

为了进一步改善与互联网规模这个需求相关的行为,我们添加了分层系统架构约束,为整个系统的复杂性设置了边界,并且提高了底层独立性。我们能够使用层级来封装遗留服务,使新的服务免受遗留客户端的影响。

中间件还可以支持负载均衡来改善系统的可伸缩性。然而,分层系统会增加数据处理的开销和延迟,因此降低用户感知的性能。不过对于一个支持缓存的架构来说,则可以通过在中间层使用共享缓存来弥补这一缺点。此外还可以通过这些中间层实施安全策略(比如防火墙)。

ulccss

分层系统架构约束与统一接口架构约束相结合,产生了与统一管道和过滤器风格类似的架构属性。在REST中,中间组件能够主动的转换消息的内容,因为这些消息是自描述的,并且其语义对于中间组件是可见的

按需代码

我们为REST添加的最后架构约束来自基于网络应用的架构风格的按需代码约束,REST允许通过下载并执行applet形式或脚本形式的代码,对客户端的功能进行扩展。这样通过减少预先实现的功能的数目,简化了客户端的开发,允许部署之后下载功能代码也改善了系统的可扩展性。但是这样做降低了可见性(REST的连接器和组件并无法理解这些脚本),因此它只是REST的一个可选的架构约束

rest风格

风格推导小节

REST架构风格由一组经过选择的架构约束组成,通过这些架构约束在候选架构上产生所期待的架构属性,夏天是根据基于网络应用的架构风格图形化描述了REST架构风格的架构约束来源

推导REST

本篇文章主要是对rest风格的推导,下一篇文章会介绍REST架构中的架构元素