• 前言：REST 表征状态传输（英文：Representational State Transfer，简称REST）是Roy Fielding博士于2000年在他的博士论文中提出来的一种软件架构风格。两年后，Roy Fielding和Richard N. Taylor署名发表论文Principled Design of the Modern Web Architecture，系统介绍了REST Web Architecture在现代Web架构环境下扮演的角色和作用，蕴含REST设计思想及原则。本人以有限的英文水平对此论文进行中文翻译。

关于论文标题 Principled Design of the Modern Web Architecture，本译文中将其翻译为 关于现代Web架构的原则性设计，因为“原则性”代表约束性，RESTful本身是一种Web设计风格，是对Web架构设计的约束的抽象体现。

• Translator: Kerwin Koo

正文：

Title: Principled Design of the Modern Web Architecture

Author: Roy T. Fielding and Richard N. Taylor

摘要

万维网(The World Wide Web)的成功，在很大程度上是因为它的 软件体系架构^[1] 在设计上更加符合互联网规模（Internet-scale）的分布式超媒体系统。现代Web架构强调的是组件交互的可拓展性（scalability of component interactions），接口的通用性（generality of interfaces），组件之间的部署独立性（ndependent deployment of components）和中间化组件（intermediary components）来减少交互延迟，确保执行安全，并对 保留系统^[2] 进行封装。在本论文中，我们介绍了表征性状态传输的架构风格，作为一种Web架构的抽象模型，来指导我们对超文本传输协议和 统一资源标识符^[3] 的设计和定义。我们描述了REST的软件工程学方面的指导原则和保留这些原则在交互上的限制，并与其他架构风格的约束做对照。然后我们会与当前部署的一些Web架构的的抽象模型做比对，来引出目前一些协议和他们所对应的应用程序之间的不协调。

关键字

软件架构（software architecture），软件架构模式（software architectural style）， WWW

1 前言

一开始，还在IETF小组（Internet Engineering Task Force）致力于定义 HTTP 1.0^[4]协议并为新标准 HTTP 1.1^[5] 和 URI^[6]（Uniform Resource Identifiers ）做延伸时，我们就已经意识到，我们缺少一种模型（model）来描述万维网到底应该怎样运作。这种理想化的交互模型，存在于整个Web应用中，正如我们所提出的REST结构模式，立足于现代Web体系结构的基础，在Web架构部署之前，提供识别已存于架构中的缺陷和拓展验证的指导原则。

软件的体系架构决定了该系统中各元素之间如何交互和分配，元素之间如何相互作用形成系统，交互所需要的通信量和通信密度（the amount and granularity of communication）以及通信接口协议。体系架构风格是体系架构在功能实现等关键方面的集合的抽象体现，它囊括了架构内重要组件及其设计，并强调架构各元素和元素间关系的约束^[7]。换句话说，风格，指的是对每一个遵守这种风格的协集架构^[8]的约束，对架构组成元素的 角色/特征^[9]及各元素间所允许的交互关系进行限制。

REST是一种在最小化网络组件交互耦合性的同时最大化组件实现的独立性和可控性。通过规范连接层而不是其他风格那样规范组件层来实现。REST使关系缓存及复用，组件动态替换，中间件行为可操作成为可能，从而满足互联网规模的分布式多媒体系统的需求。

现代Web就是一种REST风格架构的一个实例。虽然基于网络的应用程序可以包括与其他架构风格交互的接口，但他们的协议和性能问题的重心仍是分布式超媒体。REST只着重阐述那些在互联网级分布式多媒体交互最重要的部分。在Web架构优化领域存在这样一个现象，现存的协议很难表达在各组件交互过程中可能存在的全部语义，并且某些语法细节可以用一些更加高效的框架来代替，并且不改变现有架构功能。同样地，将 后继扩展^[10] 与REST进行比较，来看是否还符合架构要求；如果不符合，那么在不改变功能的情况下，使用一个更恰当的架构风格来运行系统，会更有效率^[11]。

本论文提出REST时，已在完成现代（1993年后）Web系统架构标准方面工作长达六年。这里并不会强调架构本身细节，因为这些都包含在标准之内。相反，我们重点专注于那些并未被发表的、位于现代Web架构设计和软件工程原则底层的基础理论。在这个过程中，我们会明确出当前Web协议哪些地方与架构风格不相符，通过健全协议，可以短时间内完善这些缺陷，并且以在交互风格架构使用中学到的经验，来指导分布式架构的设计。

2 万维网网域特征

为了更好地理解REST原理，我们首先回顾一下WWW项目的目标，以及为实现这些目标，而需要信息系统所具备的特征。

Berners-Lee^[12] 有言：“网络的主要目标是成为一个共享的信息空间，通过它人和机器可以交流。“我们需要一种方式来根据实际情况，长期或临时存储和组织用户的信息，它可以被多方使用，也可以被他人引用或重构到新的信息存储，因此它无需为每人维持一个本地副本。通过Internet使用该系统人可以遍布全世界，在不同的大学，政府，物理研究实验室。他们的终端设备是多种多样的，可以是工作站，服务器和超级计算机，运行着各种各样的操作系统和文件系统。信息范围从个人的研究记录到机构电话监听各个领域。它的目标，是要建立一个系统，提供通用且统一的组织信息接口，兼容多种平台，并逐渐向新组织和个人开放或允许加入项目。

选择超媒体作为用户接口是因为它的简易性和通用性：使用统一接口可以忽略信息源，超媒体关系（链接）的灵活性对信息结构没有要求，并且直接对链接进行操作，可以允许信息内部复杂的关系，来引导用户使用应用。在大型数据库中，信息往往是被用于搜索而不是浏览，网络也因此拓展出根据用户输入的数据进行简单的查询服务，进而以超媒体的方式来展现的功能。

超媒体交互的可用性对用户体验的时间延迟----从用户点击链接到展现出有价值的结果的时间----高度敏感。由于网络信息的来源覆盖整个因特网，因此网络架构需要网络交互（协议内部交互）的耦合度达到最小。在应用交互的整个过程中，延迟产生于以下几点：

• 1）客户端识别用户行为并对该行为进行分析的初始化操作所用的时间；
• 2）设置组件交互所需要的时间；
• 3）将交互传送给组件所需要的时间；
• 4）组件间执行以上交互所需要的时间；
• 5）在用户终端能够开始呈现一个可用结果之前，需要完成全部传输和处理结果的时间。

需要强调的是，虽然只有（3）和（5）代表实际的网络通信，但以上五点均被包含在架构风格的范畴之内。此外，多元化非并行交互也会增加延迟时间。

由于对统一资源的引用数和对此信息感兴趣的人数成正比，尤其是有新闻价值的信息将会导致“瞬间高峰”----突然而至的访问高峰----因此可拓展性也是一个重点。

由于参与信息的组织和加工的各方是志愿的，因此准入门槛需要足够低（来吸引更多加入者）。当分布式系统的初步部署变得简单化时，拓展性确保我们不会因为该系统的条件限制而卡住，使其无法部署。即使目前软件系统可以完美符合用户需求，但随着社会环境的变化和时间的推移，用户的需求也会随之改变。一个像万维网一样长期运作的系统需要做好更深层的准备，因为组成网络应用的各个环节直接往往是跨界的，（当新需求增加时）需要系统能够利用其可拓展性，做逐渐的适应及零散的改变，使新旧需求共存而不妨碍新需求的实现。

所有的这些项目目标和信息系统的特征组成了网络的架构设计。万维网的发展已足够有能力支撑更大的合作和分布协作^[13]。这些我们所引入的新的目标向我们提出了一个挑战：在一个被如此广泛地部署的架构中如何成功地再引入一组新功能，我们如何保证它所引入的新的功能不会排异，甚至瘫痪掉目前已在使用的Web网络架构功能？正是这个问题促使了我们对REST架构风格的开发。

3 表征状态传输（REST）

表征状态传输（REST）风格是一种分布式超媒体的元素抽象化架构。Perry和Wolf^[14] 将架构元素分为三种：处理层元素（即组件），数据元素和连接层元素（即连接口）。REST并不是强调组件该如何实现或通信协议语法该如何拟定，它专注于架构中各组件所扮演的角色和作用， 对组件间的交互进行约束，以及对重要的数据元素进行释义。它包含对各组件、接口、数据等组成Web架构的基础组成部分的约束和基于网络的应用的各部分功能的本质。

我们会运用软件架构学的基础框架，首先定义在REST风格中构成架构的各个元素，并对架构原形中的程序组件、接口和数据表现做样本剖析，以便更好地了解REST的设计原则。

数据元素

不会像分布式对象^[15]风格那样把所有的数据都封装并且通过程序组件进行隐藏，架构的数据元素的性质和状态是REST的一个关键点。这种设计原则在分布式超媒体性质中也有体现。

当一个链接被选中时，信息需要从存储它的地方，移动到使用它的地方，通常情况下，后者是用户浏览器。这跟绝大多数的分布式处理范式有明显反差，因为传递处理方法要比传递数据效率更高^[16]。分布式超媒体架构的数据操作共分三种：1）对数据进行原地渲染，并将处理后的结果镜像发送给接收者；2）将数据与渲染引擎一起封装，再发给接受者；3）将原始数据及描述该数据类型的元数据共同发送给接收者，让接受者自行选择渲染引擎。

三种数据操作方式各有利弊。第一种方案，传统的Client/Server架构^[17]风格，可以将原始数据完好地封装在发送者内部，防止原始数据被修改，使客户端更容易实现；然而它也严重制约了客户端的功能，增大了发送方的负载，导致拓展性问题。第二种方案，移动终端的处理风格[^mobile object style]，通过其对应的渲染引擎对数据进行专门处理，同时也保证了数据的隐蔽性；但这种方式同样将客户端的功能限制在渲染引擎之内，并在一定成都上增加了数据的传输负载。第三种方案使发送方变得简单和可拓展，同时最大限度减少传送的字节数；但它失去了信息隐藏的优势，并要求发送方和接收方可以解析相同的数据类型。

REST在数据传输方面对以上三种方案进行了混合，将元数据的数据类型共享，通过限制标准接口对外暴露的作用域来实现（数据传输）。REST将数据匹配入可以不断拓展的表征状态集中，接收者根据自身功能或请求，动态地选择该数据的某种表现形式来进行传输。无论数据的该标准是原数据格式相同，还是由原数据衍生而出，都会隐藏在接口下。对于移动终端来说，类似于通过传输适用于该解析引擎（e.g. Java）的标准格式的数据表征。而对于C/S架构类型，REST即实现组件分离，又解决了服务端的拓展性问题，并将信息隐藏在接口下，可以对服务进行更好的封装和迭代，通过可更新功能引擎（downloadable feature-engines）来提供动态功能集。

表1：REST数据元素及解释举例