语言 Chinese, Simplified

SEO Title

REST 是 REpresentational State Transfer 的首字母缩写词，是分布式超媒体系统的一种架构风格。罗伊菲尔丁于 2000 年在他的著名论文中首次提出了它。

与其他架构风格一样，REST 有其指导原则和约束。如果需要将服务接口称为 RESTful，则必须满足这些原则。

符合 REST 架构风格的 Web API（或 Web 服务）是 REST API。

1. REST 的指导原则

RESTful 架构的六个指导原则或约束是：

1.1 统一接口

通过将通用性原则应用于组件接口，我们可以简化整个系统架构并提高交互的可见性。

多个架构约束有助于获得统一的接口并指导组件的行为。

以下四个约束可以实现统一的 REST 接口：

资源标识——接口必须唯一标识客户端和服务器之间交互中涉及的每个资源。
通过表示(REpresentation)操作资源——资源在服务器响应中应该有统一的表示。 API 使用者应该使用这些表示来修改服务器中的资源状态。
自描述消息——每个资源表示应该携带足够的信息来描述如何处理消息。它还应该提供客户端可以对资源执行的附加操作的信息。
超媒体作为应用程序状态的引擎——客户端应该只有应用程序的初始 URI。客户端应用程序应该使用超链接动态驱动所有其他资源和交互。

1.2.客户端-服务器

客户端-服务器设计模式强制关注点分离，这有助于客户端和服务器组件独立发展。

通过将用户界面关注点（客户端）与数据存储关注点（服务器）分离，我们提高了用户界面跨多个平台的可移植性，并通过简化服务器组件来提高可扩展性。

在客户端和服务器发展的同时，我们必须确保客户端和服务器之间的接口/契约不会中断。

1.3.无状态

无状态要求从客户端到服务器的每个请求都必须包含理解和完成请求所需的所有信息。

服务器无法利用服务器上任何先前存储的上下文信息。

因此，客户端应用程序必须完全保持会话状态。

1.4.可缓存

可缓存约束要求响应应隐式或显式地将自身标记为可缓存或不可缓存。

如果响应是可缓存的，则客户端应用程序有权在稍后为等效请求和指定时间段重用响应数据。

1.5 分层系统

分层系统样式允许通过约束组件行为来由分层层组成架构。

例如，在分层系统中，每个组件都无法看到它们正在与之交互的直接层之外。

1.6 按需编码（可选）

REST 还允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。

下载的代码通过减少需要预先实现的功能数量来简化客户端。服务器可以将部分功能以代码的形式交付给客户端，客户端只需要执行代码即可。

2. 什么是资源？

REST 中信息的关键抽象是资源。我们可以命名的任何信息都可以是资源。例如，REST 资源可以是文档或图像、临时服务、其他资源的集合或非虚拟对象（例如，人）。

资源在任何特定时间的状态称为资源表示。

资源表示包括：

数据
描述数据的元数据
以及可以帮助客户过渡到下一个所需状态的超媒体链接。

一个 REST API 由一组相互关联的资源组成。这组资源称为 REST API 的资源模型。

2.1资源标识符

REST 使用资源标识符来识别客户端和服务器组件之间交互中涉及的每个资源。

2.2.超媒体

表示的数据格式称为媒体类型。媒体类型标识了一个规范，该规范定义了如何处理表示。

RESTful API 看起来像超文本。每个可寻址的信息单元都带有一个地址，可以是显式的（例如，链接和 id 属性），也可以是隐式的（例如，源自媒体类型定义和表示结构）。

超文本（或超媒体）意味着信息和控制的同时呈现，使得信息成为用户（或 automaton）获得选择和选择动作的可供性。

请记住，超文本在浏览器上不需要是 HTML（或 XML 或 JSON）。当机器了解数据格式和关系类型时，它们可以跟踪链接。

— Roy Fielding

2.3.自我描述

此外，资源表示应该是自描述的：客户端不需要知道资源是员工还是设备。它应该根据与资源相关联的媒体类型进行操作。

所以在实践中，我们将创建许多自定义媒体类型——通常是一种媒体类型与一种资源相关联。

每种媒体类型都定义了一个默认处理模型。例如，HTML 定义了超文本的呈现过程以及每个元素周围的浏览器行为。

媒体类型与资源方法没有关系，得到/ put / post / delete / ......除了某些媒体类型元素将定义像href属性的锚元素的进程模型的事实之外，veroct方法，在对应于 CDATA 编码的 href 属性的 URI 上调用检索请求 (GET)。”

3. 资源方法

与 REST 相关的另一件重要事情是资源方法。这些资源方法用于在任何资源的两种状态之间执行所需的转换。

很多人错误地将资源方法与 HTTP 方法（即 GET/PUT/POST/DELETE）相关联。 Roy Fielding 从未提及任何关于在何种条件下使用哪种方法的建议。他所强调的只是它应该是一个统一的界面。

例如，如果我们决定应用程序 API 将使用 HTTP POST 来更新资源——而不是大多数人推荐的 HTTP PUT——那没关系。尽管如此，应用程序界面仍将是 RESTful。

理想情况下，转换资源状态所需的一切都应该是资源表示的一部分——包括所有支持的方法以及它们将以何种形式离开表示。

我们应该输入一个 REST API，除了初始 URI（书签）和一组适合目标受众的标准化媒体类型（即任何可能使用该 API 的客户端都可以理解）之外，没有任何先验知识。

从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动，这些选项存在于接收到的表示中，或者由用户对这些表示的操作暗示。

转换可能由客户对媒体类型和资源通信机制的了解确定（或限制），这两者都可以即时改进（例如，按需编码）。 [这里的失败意味着带外信息正在推动交互而不是超文本。]