风格架构的形成

5.3.2　REST风格架构的形成

使REST架构风格区别于其他基于网络的架构风格的核心特征是，它强调组件之间要有一个统一的接口（如图5-3左图所示），即统一接口约束。通过在组件接口上应用通用性的软件工程原则，整体的系统架构得到了简化，交互的可见性也得到了改善。实现与它们所提供的服务是解耦的，这促进了独立的可进化性。然而，统一接口降低了效率，因为信息都使用标准化的形式来转移，而不能使用特定于应用需求的形式。REST接口被设计为可以高效地转移大粒度的超媒体数据，并针对Web的常见情况做了优化，但是这也导致了该接口对于其他形式的架构交互并不是最优的。

为了获得统一的接口，需要有多个架构约束来指导组件的行为。REST由四个接口约束来定义：资源的识别（Identification of resources）、通过表述对资源执行的操作、自描述的消息（Self-descriptive messages）以及作为应用状态引擎的超媒体。

为了进一步改善与Internet规模的需求相关的行为，REST架构风格添加了分层的系统约束（如图5-3中图所示）。分层系统约束通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。通过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，并且提高了底层独立性。能够使用层来封装遗留的服务，使新的服务免受遗留客户端的影响，通过将不常用的功能转移到一个共享的中间组件中，从而简化组件的实现。中间组件还能够通过支持跨多个网络和处理器的负载均衡，来改善系统的可伸缩性。

分层系统约束的主要缺点是：增加了数据处理的开销和延迟，因此降低了用户可觉察的性能。对于一个支持缓存约束的基于网络的系统来说，可以通过在中间层使用共享缓存所获得的好处来弥补这一缺点。在组织领域的边界设置共享缓存能够获得显著的性能提升。这些中间层还允许对跨组织边界的数据强制执行安全策略，如防火墙所要求的安全策略。

分层系统约束和统一接口约束相结合，形成了与统一管道和过滤器风格类似的架构属性。尽管REST的交互是双向的，但是超媒体交互的大粒度的数据流每一个都能够被当做一个数据流网络来处理，其中包括一些有选择地应用在数据流上的过滤器组件，以便在数据传递的过程中对它的内容进行转换。在REST中，中间组件能够主动地转换消息的内容，因为这些消息是自描述的，并且其语义对于中间组件是可见的。

为REST添加的最后的约束来自于按需代码（如图4-3右图所示）。通过下载并执行Applet形式或脚本形式的代码，REST允许对客户端的功能进行扩展。这样，通过减少必须被预先实现的功能的数目，简化了客户端的开发。允许在部署之后下载功能代码也改善了系统的可扩展性。然而，这也降低了可见性，因此它只是REST的一个可选的约束。（如图5-3所示）显示了从统一接口-客户机-缓存-无状态-服务器风格到统一接口-分层-客户机-缓存-无状态-服务器风格最后到REST风格的变化。

图5-3　统一接口-客户机-缓存-无状态-服务器风格到REST风格的变化图

可选的约束想法似乎有些矛盾。然而，在设计一个包含多个组织边界的系统架构时，它确实是有用的。这意味着只有当已知对于整个系统的某些领域有效的情况下，架构才会从可选的约束得到好处（或蒙受损失）。例如，如果已知一个组织中的所有客户端软件都支持Java Applet，那么该组织中的服务就能够构造为可以通过下载Java类来增强客户端的功能，以便从可选的约束得到好处。然而，与此同时，该组织的防火墙可能会阻止转移来自外部资源的Java Applet，因此对于Web的其余部分来说，这些客户端似乎是不支持按需代码的。一个可选的约束允许设计在一般的场合下支持期待的行为的架构，但是这些行为可能在某些环境中无法使用。

REST由一组选择用来在候选架构上想要得到的属性的架构约束组成。尽管这些约束每一个都能够独立加以考虑，但是根据它们在通用的架构风格中的来源来对它们进行描述，使得理解选择它们背后的基本原理更加容易。如图5-4所示基于网络的架构风格图形象化地描述了REST约束的来源。

图5-4　REST所继承的风格约束