表述性状态转移：简要概述

引言

随着过去十年互联网的发展，托管其服务所需的基础设施以及支持如此大规模开发模式的开发范式也发生了重大变化。这种基础设施的规模和演变催生了各种技术，例如，从容器内的数据中心到“芯片上的云”[Intel]。同样，软件开发语言和范式也经历了从通过 cgi-bin 托管的脚本 [Perl、csh 和 bash] 到基于虚拟机的应用程序服务器 [如 Tomcat、.NET、Parrot] 的演变。采用现代语言来支持如此大规模的开发和并行处理，也带来了架构风格的变化。当前流行的并且已被证明是成功的风格是面向服务的架构。这些风格在底层基础设施和社区的开发套件中找到了协同作用，从而增加了它们的采用率。目前，基于 REST 的系统在处理大规模基础设施的开发和部署所需的概念模型方面显示出巨大的潜力。在本文中，我们将介绍 REST 思想的起源、其概念以及随后的行业采纳情况。

Representational State Transfer

REST 最初由 Roy Fielding 于 2000 年在加州大学欧文分校的学术论文《网络化软件架构风格与设计》中提出并定义。它是一种源自许多现有网络架构风格的架构风格。它作为 Web 标准和 Web 服务设计的指导框架。它通过使用现有的 Web 标准并对其施加约束来充分利用 Web 的潜力，以确保对成熟的分布式超媒体系统的建模。

REST 架构风格

在设计任何分布式超媒体系统（现代 Web 架构）时，应确保可伸缩性、简洁性、可见性等各种因素。现有的网络架构风格确实能确保这些因素。但是，没有现有的风格能够将所有这些风格组合起来并反映这些期望的属性。REST 是通过识别现有网络风格的优缺点而演变而来的。构成 REST 的网络风格是：

• 客户端-服务器：客户端-服务器约束确保与数据视图（即用户界面）相关的关注点与其在服务器上的存储方式分离。数据与其视图之间的这种松耦合有助于客户端移植到各种技术。服务器也独立于客户端的任何技术约束。因此，服务器和客户端都可以独立演进。
• 客户端-服务器：客户端-服务器约束确保与数据视图（即用户界面）相关的关注点与其在服务器上的存储方式分离。数据与其视图之间的这种松耦合有助于客户端移植到各种技术。服务器也独立于客户端的任何技术约束。因此，服务器和客户端都可以独立演进。
• 无状态：无状态约束确保每个请求都是完整且独立的。这简化了监控。无需关联多个请求。通过分析单个请求即可快速恢复故障。确保可伸缩性，因为服务器不存储任何客户端状态。服务器可以在处理完单个请求后立即释放其资源。
• 可缓存：缓存消除了部分客户端-服务器交互。它缓存不经常更改的信息。这提高了整体用户感知的性能。将缓存添加到各种组件有助于进一步减少网络和带宽使用。例如，通过在客户端（如代理）实现缓存，请求不必总是发送到源服务器。因此，信息可以快速提供给客户端。
• 分层系统：通过将整个系统分层，可以降低系统的复杂性。每一层只需要知道如何与下一层交互。每一层都有其自身的责任。因此，整个系统可以轻松管理。
• 按需加载代码：客户端可以在运行时下载功能并执行代码。可执行代码可以是小程序或脚本的形式。然而，此约束并非总是可以确保。某些组件（如防火墙）可能不允许可执行代码通过网络。因此，此约束在 REST 中被添加为可选。
• 统一接口：当系统由许多组件组成时，它们之间的通信变得困难。所有组件都需要理解通信的合同和协议。通过拥有统一的接口，组件不必理解应用程序特定的语义。这使得通信更加容易。为了实现统一的接口，对组件的行为施加了一些约束。这种行为在 REST 风格中也称为数据元素。

REST 架构元素

数据元素

REST 的关键在于其数据元素的性质和状态。在 REST 风格中，有四个概念描述了信息的行为和状态。它们是：

• 资源：它是 Web 上可用的实体（逻辑/物理）。它可以是服务器文件系统中存储的文档，也可以是数据库表中的一行。最终用户与资源交互以实现某个目标。为了设计一个 REST 系统，设计者必须将业务实体视为资源，并考虑如何使这些资源可寻址。
• URI：它唯一标识一个资源。它使资源可寻址且可修改。资源和 URI 之间存在一对多关系。资源使用 HTTP 等应用程序协议进行更改。
• 表示：它是资源的 [数据/元数据]。表示是在某个时刻资源状态的视图。当请求 URI 时，客户端会收到资源的表示。资源的视图可以编码成一种或多种可传输的格式，如 XML、HTML、JSON、RSS 等。可以使用内容协商机制来协商这些格式。
• 链接：它允许应用程序从一个状态转换到另一个状态。每个资源都应与其他资源连接。表示应提供指向下一个转换的链接。一个连接良好的应用程序允许用户自行发现接口。

连接器

连接器是一种抽象接口，它在组件之间进行通信。由于 REST 交互是无状态的，连接器不必存储任何状态信息。因此，组件之间的通信可以并行进行。

客户端和服务器是主要的 REST 连接器。客户端发起请求，服务器处理请求。例如：

• 服务器连接器：Apache API
• 客户端连接器：Http Client

缓存是另一个连接器。缓存可以在客户端、服务器或中间层实现。它可减少延迟和网络使用。各种缓存类型包括：

• 本地缓存：它代表单个用户代理存储来自各种源服务器的资源表示。
• 代理缓存：它代表许多用户代理存储来自各种源服务器的资源。
• 反向代理缓存：它代表一个源服务器存储供许多消费者使用的资源。

解析器：它将部分或完整的请求转换为资源的实际地址。它负责启动和排序最终导致资源完全解析的查询，例如，使用 DNS 解析器将域名转换为 IP 地址。

Components

组件对资源执行一组定义明确的方法，生成表示以捕获该资源的当前或预期状态。

• 用户代理：它使用客户端连接器发起请求。
• 源服务器：它使用服务器连接器响应请求。
• 代理：它是客户端端的中间件，用于提供其他服务的接口封装。它还执行数据转换和安全保护。
• 网关：它是服务器端的中间件，用于提供其他服务的接口封装。它还执行数据转换和安全保护。

HTTP 与 REST

超文本传输协议在 Web 架构中扮演着非常特殊的角色。其主要作用是作为 Web 组件之间通信的应用协议。它作为传输协议用于传输资源表示。为了现代 Web 架构，HTTP 进行了许多更改。

HTTP 与缓存

REST 强制执行了一些关于 HTTP 标头使用的指南，以利用缓存的优势。这提高了网络效率。其思想是对这些 HTTP 标头在与不同 HTTP 方法一起使用时施加语义约束。例如，对于 HTTP GET 和 HEAD 方法，这些标头的语义是缓存刷新 (Cache-Control)。对于其他 HTTP 方法，这些标头的含义是前提条件。

缓存信息作为控制数据发送在资源表示中。这些控制数据告诉客户端是否缓存响应，例如 Cache-Control 等。“Vary”标头在 HTTP 1.1 中引入。此标头列出了响应资源表示可能变化的标头。例如，如果“Vary”标头列出了 Accept 标头，则意味着具有不同的 Accept 标头值，表示是不同的。缓存会在向客户端返回响应时使用此标头。

当缓存引入到各个层时，假设有时消费者可以使用过时的数据。为了提高缓存数据与实际数据的[一致性程度]，REST 中添加了一些技术。无效化 (Invalidation) 是通知消费者和缓存有关它们持有的缓存表示的资源所发生更改的过程。但是，要通知消费者，服务器需要拥有所有消费者的列表。这违反了 REST 的指导原则。为了解决这个问题，使用了另一种称为验证 (Validation) 的技术。它涉及消费者（缓存）通过验证本地副本与源服务器来维护资源的最新副本。这需要将某种验证请求发送到服务器。为了重新验证本地数据副本与源服务器，REST 在条件 GET 请求中使用了两个 HTTP 标头：ETag 和 If-Match/If-None-Match 标头，以及 Last-Modified 和 If-Unmodified-Since/If-Modified-Since 标头。

HTTP 中的问题区域

REST 识别的 HTTP 中的关键问题区域包括：

• 新协议版本部署：组件之间的通信要求连接器必须遵守包含在每个消息中的 HTTP 版本协议元素的约束。REST 通过使用 HTTP 协议的次要和主要版本来尝试解决此问题。消息的 HTTP 版本表示发送者的协议能力以及所发送消息的[粗略兼容性（主版本号）]。例如，如果发送者使用 HTTP 1.0 发送请求，服务器应发送与 HTTP 1.0 兼容的响应。通过这种方式，请求/响应链上的每个连接都可以以其最佳协议级别运行，尽管链中某些客户端或服务器存在限制。这种机制使系统具有可扩展性。
• 消息解析与 HTTP 语义分离：通过新的更改，HTTP 协议将 HTTP 消息的解析和转发逻辑与与 HTTP 协议元素相关的语义分离开来。例如，对于 HEAD，content-length 字段的含义与响应长度不同（HEAD 类似于 GET 请求，唯一区别是响应未发送，但元信息（标头）如 content-length 被发送。因此，在这种情况下，content-length 表示如果请求是 GET 请求，将发送的响应的长度）。以及通用响应代码的使用：
  • [] 100-199 表示消息包含临时信息响应
  • [] 200-299 表示请求成功
  • [] 300-399 表示请求需要重定向到另一个资源
  • [] 400-499 表示客户端出现错误，不应重复
  • [] 500-599 表示服务器遇到错误。
• 自描述消息：每条消息都以标准化格式包含所有信息以供处理。REST 引入了一些标头和技术来实现这一点。例如：
  • Host：HTTP 1.1 中添加了 HOST 标头。此引入使得 IP 地址可以在不同域之间共享。它要求每个请求都发送此标头，其中包含主机名。目前许多浏览器在请求中不发送 HOST 标头。在全局范围内应用此机制可能需要一些时间。
  • 内容协商：内容协商是协商资源表示并根据客户端选择进行渲染的方式。
• 持久连接：HTTP 持久连接，也称为 HTTP keep-alive 或 HTTP 连接重用。它允许使用同一个 TCP 连接发送和接收多个 HTTP 请求/响应。在 HTTP 1.1 中，所有连接默认都是持久的。要[反转]默认的连接指令，需要将“close”设置为 false。持久连接可减少资源使用，并因 TCP 连接数量较少而减少网络拥塞。
• 权威响应与非权威响应：当用户代理发起请求时，它不知道收到的响应是来自源服务器还是来自某些中间组件（如缓存）。这可能会导致用户代理想要新鲜数据但收到过时数据的情况。为了解决这个问题，引入了一些标头，使用户代理能够控制响应。在请求中添加 Cache-Control="no-cache" 标头可确保调用源服务器获取响应。批量使用此方法可能会出现性能问题。另一种解决方案是添加“Warning”标头，以警告用户代理响应不是来自源服务器。

RESTful Web 服务

RESTful Web API 是使用 HTTP 实现并遵循 REST 指导原则的 Web 服务。REST Web 服务的优势在于其开发和测试的简洁性。尽管存在现有的 WS* 标准，REST 却日益受到欢迎。其原因在于其简洁性和对现有标准的利用。

在设计 REST Web 服务时，会研究应用程序域及其实体。需要公开的实体是资源。在一个简单的聊天应用程序中，用户和用户发布的 [消息] 是资源。要访问资源，必须有一个端点供客户端使用。这些端点称为 URI。在聊天应用程序中，用户和消息使用 URI 进行访问，例如 /user/、/user/messages/ 等。当获取任何资源时，都会从服务中获取表示。例如，XML 格式的用户表示如下：Jack. 客户端可以使用内容协商来协商表示中数据的格式。REST Web 服务应发送的标准 HTTP 状态和响应代码是标准的 HTTP 状态和响应代码。

在 REST 中，CRUD（创建、读取、更新、删除）操作使用 HTTP 动词执行。HTTP 动词告诉服务器对 URL 标识的数据执行什么操作。对 RESTful 系统最重要的 HTTP 动词是GET、POST、PUT 和 DELETE。

使用 POST 创建资源

客户端可以使用 POST 创建系统中不存在的资源。POST 请求的结果可以是成功创建新资源，也可以是发生错误。如果资源成功创建，则向客户端返回 HTTP 状态码 200（成功），在这种情况下，新创建资源的链接嵌入在响应中；如果发生错误，则向客户端发送 400（错误请求）或 500（内部服务器错误）。

使用 GET 获取资源状态

客户端使用 GET 获取资源的表示。GET 请求的结果可以是 200（成功），即成功获取表示；或者发生错误/异常，例如 404（未找到资源）或 400（错误请求）或 500（内部服务器错误）。

使用 PUT 更新资源

PUT 用于更新或创建由客户端生成的 URI 标识的资源。关于何时使用 PUT 和何时使用 POST 有一个小约定，因为它在某些地方可能会令人困惑。当为资源创建 URI 时，该 URI 可以由客户端或服务器生成，例如，如果资源的标识可以从客户端生成的标识符中完成，那么在创建新资源时，客户端可以传递 URI，在这种情况下，该 URI 称为客户端生成的 URI。但是，如果标识符是在服务器上生成的，那么 URI 就是服务器生成的 URI。一般约定总结如下：

• 使用 POST 创建由服务器生成的 URI 标识的资源。
• 使用 POST 将资源附加到由服务器生成的 URI 标识的集合。
• 使用 PUT 创建或更新由客户端生成的 URI 标识的资源。

PUT 请求有四种可能的结果：200（成功）或 204（无内容）；或错误，可能是 404（未找到资源）、409（冲突）或 500（内部服务器错误）。

使用 DELETE 删除资源

当客户端决定从系统中删除资源时，可以发出 DELETE 请求。可能的结果是 200（成功）表示资源已成功删除、204（无内容）；或错误，可能是 404（未找到资源）、405（不允许的方法）或 503（服务不可用）。

REST 与安全性

REST 不提供任何内置的安全支持。在设计 REST Web 服务时，必须预先确定安全需求和设计。REST Web 服务使用 HTTP 的 GET、POST、PUT 和 DELETE 来执行 CRUD 操作。PUT 和 DELETE 不被许多浏览器支持，并且由于其安全影响，常常在服务器级别被禁用。如果服务器和客户端配置不当，任何人都可以使用 PUT 方法创建资源或使用 DELETE 方法销毁资源。在设计 Web 服务的安全需求时，应考虑以下几点：

• 确定哪些服务是公共的，哪些是受保护的。
• 对于所有受保护的服务，使用具有强加密的身份验证模型。考虑使用 HMAC（基于哈希的消息身份验证码），与 SHA（安全哈希算法）和 MD5（消息摘要算法）相比，它更安全。
• HTTP 方法（如 PUT 和 DELETE）在服务器和应用程序级别采用不同的安全原则。
• 如果状态是通过某种唯一的令牌 ID 来维护的，请确保令牌 ID 已加密。
• 客户端和服务器之间共享的任何密钥都应加密。
• 始终确保为暴露的服务定义了授权规则。
• 如果有第三方参与，请勿与其共享凭据，考虑使用 OAuth。Twitter 已采用 OAuth 来验证和授权 REST API。

REST 的商业采纳

Twitter / Amazon：Twitter 和 Amazon 都公开了 REST API。Twitter 公开了核心的 Twitter 数据，而 Amazon 的简单存储服务公开了用于存储和检索任意数量数据的 API。Amazon 公开了 REST 和 SOAP Web 服务，但 REST 因其易于客户端消费而广受欢迎。REST 引入的统一接口约束确保了服务的易用性。

Akamai（内容分发网络）：Akamai 是内容分发管理系统，它存储与 Akamai 绑定的源服务器的内容。其理念是，每当用户代理请求源服务器的任何内容时，请求都会到达 Akamai，内容将从地理位置最近的服务器进行交付。Akamai 通过将服务器复制到不同位置，并将内容从地理位置最近的复制服务器交付给用户，从而扩展了 REST 缓存概念。请求的无状态性和表示使得缓存数据以及在复制服务器中独立处理成为可能。网络性能得到了提高，因为请求不必每次都发送到源服务器，而是可以由复制服务器提供。

REST 因其轻量级特性而被许多商业应用程序所接受。其他架构风格可能以协议的形式提供这些功能并且经过定制，但 REST 的优点在于它利用现有的 Web 标准以一种复杂性更低、更通用的方式来利用 Web 的优势。

REST 与 SOAP-based Web 服务（WS*）

• SOAP-based Web 服务是协议特定的，而 REST 只是指导原则。
• 要使用 SOAP-based Web 服务，客户端需要为 Web 服务创建代理（存根），然后调用代理上的方法。而在 REST 中，客户端只需使用 URI 来访问 Web 服务，并通过对 URI 使用 HTTP GET 来调用服务。
• SOAP-based Web 服务需要外部供应商的帮助来创建代理类等，而 REST 则不需要外部供应商。
• SOAP 使用 HTTP 作为传输协议来传输 SOAP 消息。需要执行的操作包含在 SOAP 消息中。REST 使用 HTTP 作为应用协议。HTTP 动词本身就表明了需要执行的操作。
• REST WS 是无状态的，有助于扩展系统。REST 中的传输数据格式可以根据客户端的意愿选择，并且可以优化性能。

在原则层面上，WS-* 和 REST 都提供了相同的功能。但在概念和技术层面，WS-* 是一个复杂的过程，它由各种工具支持，这些工具承担了大部分复杂的过程。REST 是简单的，但需要大量的底层编码。

结论

从简单的 RPC 到 SOAP-based Web 服务，再到现在的 REST，Web 经历了巨大的变化，更多的变化是不可避免的。从 Web 1.0 到 Web 2.0，每个人都参与到 Web 中。在过去的几年里，REST 在亚马逊、雅虎等公司获得了更多的商业应用，原因在于其简洁性和易用性。REST 已发展成为现代 Web 架构的基础，它是通过分析现有风格的缺陷并引入新功能而演变而来的。REST 的目标是使用一组协调的约束来利用现有风格，以最小化延迟和网络通信，并最大化组件的独立演进以实现可伸缩性。它是分布式超媒体系统的一种新颖架构。随着移动设备、iPad 等设备越来越多，Web 的普及和可伸缩性将大幅提高。网站希望转变为 Web 服务的那一天不远了。为了消费这些 Web 服务，需要一种更标准化的风格，而 REST 提供了这种风格。未来，我们可能会看到 SOAP 和 REST 并存，SOAP 采用 REST 的指导原则。

Web 的未来

在 Web 2.0 中，人类负责创建数据。Web 3.0 的焦点将是机器创建数据。目前正在研究 Web 3.0 的重要功能，即语义网和个性化。语义网的工作已经开始，其中数据不再是关于导航链接。它更侧重于理解数据的上下文以及给定知识域内的关系。各种技术（如资源描述框架、本体）旨在提供这些功能。REST 指导原则如何帮助实现这些功能是未来值得关注的。

历史

• 2011 年 9 月 12 日：初始版本