REST初探

菜鸟学架构——自讨苦吃

公司需要使用新的框架——REST，本来应该屁颠屁颠的去学习它如何使用，可又觉得自己是不是应该先了解一些更根本的东西，以前总是盲目的去学习，比如说springMVC，可其实并不知道为什么要学它，它的本质是什么，到底解决了什么问题，为了不走以前的老路，决定在了解一个新事物之前需要对它进行追根溯源，于是有了这篇文章。花了一周时间阅读fielding大神的博士论文原文，英语渣的我表示读的快要秃顶了，好艰难！带着自己的疑问，对它进行了一些学习总结（应该说是中式翻译）。

1. 架构

想了解什么是架构，首先应该明白这些概念。

• 组件(component)：组件是软件指令和内部状态的抽象单元，它通过接口提供数据的转换。需要关注的是它能够为其他组件提供哪些服务，而不是实现本身。

• 连接器（connector）：是调节组件之前通信、协作的抽象机制。在不改变数据的情况下将数据从一个接口传输到另一个接口。

• 数据（data）：是连接器进行传输的信息。

• 属性（properties）：包括架构内所有元素的所有属性，比如性能、可扩展性、可视化、简单性、可配置性、可重用性、可移植性、可靠性。

而软件架构就是指为达到系统期望属性进行的元素配置，这些元素包括组件、连接器和数据。

注意：软件架构和软件结构的区别，软件架构是系统运行时的行为抽象，软件结构则是软件源代码的属性。

2. 架构风格

什么是架构风格？

架构风格就是一组限制，就是对架构元素的特征、角色和它们之间关系的约束。

架构风格有哪些？

以下是常见的几种架构风格：

1. Data-flow Styles

   • Pipe and Filter(PF)：管道和过滤器风格，在输入中读取数据流并在输出中产生数据流，约束是过滤器之间相互独立。

   • Uniform Pipe and Filter(UPF)：在PF风格基础上添加了一个约束，即过滤器之间必须有相同的接口。

2. Replication Styles

   • Replicated Repository(RR)：复制存储库风格的系统通过使多个进程提供相同的服务来提高数据的可访问性和服务的可伸缩性，主要关注点在保持一致性。

   • Cache($)：将从服务器响应的结果存储下来，下次请求可直接发送给客户端，而不需要再经过服务器。

3. Hierarchical Styles

   • Client-server(CS)：CS架构这是最常见的一种架构风格，即客户端发送请求，服务器响应请求，约束是关注分离，这样的好处在于提高了扩展性，简化了服务端，组件能够独立发展。

   • Layered system(LS) and Layered-Client-Server(LCS)：分层系统有组织层次，每一层都为上一层提供服务，优点是可重用和隐藏内部结构，缺点是降低了网络性能。

   • Client-Stateless-Server (CSS)：CSS架构风格在CS的基础上添加了服务端无会话状态的约束。服务器无需存储会话状态能够加快资源释放，并简化实现。

   • Client-Cache-Stateless-Server (C$SS)：在CSS基础上添加缓存组件，提高效率和用户感知性能。

   • Layered-Client-Cache-Stateless-Server (LC$SS)：由LCS和Client-Cache-Stateless-Server 结合产生，另外添加了代理或者网关组件。

   • Remote Session (RS)： 远程会话风格是CS的一种变体，最小化客户端组件而不是服务器组件的复杂性或最大化重用。

   • Remote Data Access (RDA)：远程数据访问也是CS的一种变体，在客户端和服务器之间传递应用程序的状态。优点在于，可以在服务器端减少大的数据集而不在网络上传输它，从而提高了效率，缺点是客户端需要理解与服务器实现相同的数据库操作概念（缺乏简单性）。

4. Mobile Code Styles

   • Virtual Machine (VM)
   • Remote Evaluation (REV)
   • Code on Demand (COD)
   • Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)
   • Mobile Agent (MA)

5. Peer-to-Peer Styles

   • Event-based Integration (EBI)
   • Distributed Objects
   • C2
   • Brokered Distributed Objects

3. REST

什么是REST

Web体系结构背后的设计理念可以通过由应用于体系结构内的元素的约束集合构成的架构风格来描述。 通过检查每个约束，我们可以识别Web约束引起的属性。 附加约束来形成更好地反映现代Web体系结构的期望属性的新的架构风格，REST就是一种从无到有，不断根据需求添加约束而形成的新的混合架构风格。

有哪些约束

• client-server：关注分离

• stateless：无状态

• cache：缓存，缺点是可能会出现缓存内容和源服务器资源不一致的情况（当缓存资源过期的时候）

• uniform interface：统一接口，这个约束是和其他架构风格最重要的区别。它简化了系统架构，将实现和提供的服务分离，易于独立演进，对大粒度超媒体数据传输是高效的，优化了web一些常见情况，但是统一接口却降低了效率，因为信息需要以标准化形式传输，而不是按特定的应用需求。为了获得均匀的接口，需要多个架构约束来指导组件的行为，REST由以下几个约束定义：资源的识别、通过表示操作资源、自我描述信息、超媒体作为应用状态引擎

• Layered system：分层系统

• Code-On-Demand：REST允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能，是一个可选约束。

REST的元素

REST风格是基于分布式超媒体提供的架构元素的抽象，元素包括组件、连接器、数据元素。

1） component：

2） connectors：

连接器的作用：封装访问资源和传输资源表示的活动。

连接器接口类似于过程调用，但在传递参数和结果方面有重要的区别。以下是连接器接口的输入输出：

in-parameters：请求控制数据（request control data）、资源标识（resource identifier）、表示（option representation）
out-parameter：响应控制数据（response control data）、资源（option resource data）、表示（option representation）

3） data element ：

REST风格将所有数据都封装在处理组件中，由处理组件隐藏。这样做有几个原因和几大好处。

【原因】
首先分布式超媒体系统有三个数据处理选择：第一，在数据存储的地方渲染数据，发送给接收者；第二，使用专门的渲染引擎来封装数据，发送给接收者；第三，将原始数据和元数据一同发送给接收者，接收者可以选择自己的渲染引擎。
但事物总有它的利弊。
第一种方式是属于传统的客户端-服务器风格，它把数据的所有信息都隐藏在发送方，简化了客户端实现，但大量数据处理都放到发送方会导致可扩展问题；第二种是移动对象风格，它也提供信息隐藏，通过专门的渲染引擎实现数据处理，但接收者的功能却同时受到该引擎的功能限制，并且可能大大增加传输的数据量；最后一种允许发送方保持简单和可扩展，但丢失了信息隐藏的优点，而且这种方式要求发送发和接收方都要理解数据类型

【优点】
为了达到更好的效果，选择了一个合理折中的处理方式，REST将三种方式融合到一起，即组件通过传送资源的表示来通信，过程中可以根据接收者的能力或期望和资源的属性动态选择一种合适的格式。无论表现是与原生source还是source的派生有相同格式，都保持隐藏在接口后面，通过发送由标准数据格式指令组成的表现来达到类似移动对象风格的优势。因此，REST获得了客户端服务器的分离，但服务器的可扩展性却没有受到限制，而且通过接口隐藏信息来实现服务的封装和演进，通过下载的特征引擎提供多种功能。

注意：
1、 REST是基于分布式超媒体系统（超媒体=超文本+媒体内容）
2、 REST忽略具体的实现细节，而将注意力集中到组件的角色、组件之间交互的约束和重要数据元素的解释。
3、 REST不直接操作资源，而是通过表示。

最后，后续应该要解决的问题是：REST如何使用？分别在哪些场景中使用？哪些场景不能使用？

真的勇士，要敢于挑战自己：http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm