表述性状态传输 —REST

什么是REST？

REST是表述性状态传输( REpresentational  State Transfer)的缩写 ，是分布式超媒体系统的一种架构风格 。 Roy Fielding 于 2000 年在他的著名论文中首次提出了这一点 。从那时起，它已成为构建基于 Web 的 API（应用程序编程接口）的最广泛使用的方法之一。

REST 不是一种协议或标准，而是一种架构风格。在开发阶段，API 开发人员可以通过多种方式实现 REST。

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

REST 的六大指导原则

REST 基于一些促进设计简单性、可扩展性和无状态性的约束和原则。RESTful 架构的六个指导原则或约束是：

 

1.统一接口

通过将 通用性原则应用于 组件接口，我们可以简化整个系统架构并提高交互的可见性。多个架构约束有助于获得统一的接口并指导组件的行为。

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

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

简而言之，REST 为客户端和服务器之间的交互定义了一致且统一的接口。例如，基于 HTTP 的 REST API 使用标准 HTTP 方法（GET、POST、PUT、DELETE 等）和 URI（统一资源标识符）来标识资源。

2.客户端服务器

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

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

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

3.无国籍

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

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

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

4.可缓存

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

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

5.分层系统

分层系统风格允许通过约束组件行为来将体系结构由层次结构层组成。在分层系统中，每个组件都无法看到与其交互的直接层之外的内容。

分层系统的外行示例是MVC 模式。 MVC 模式允许清晰地分离关注点，从而更轻松地开发、维护和扩展应用程序。

6.按需编码（可选）

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

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

什么是资源？

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

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

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

1.资源标识符

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

2.超媒体

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

RESTful API 看起来像超文本。每个可寻址信息单元都携带一个地址，或者显式地（例如，链接和id属性）或者隐式地（例如，从媒体类型定义和表示结构导出）。

3.自描述

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

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

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

资源方法

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

很多人错误地将资源方法与 HTTP 方法 （即 GET/PUT/POST/DELETE）联系起来。罗伊·菲尔丁 (Roy Fielding) 从未提及过在哪种情况下使用哪种方法的任何建议。他只是强调它应该是一个 统一的界面。

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

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

REST 和 HTTP 不一样

许多人更喜欢将 HTTP 与 REST 进行比较。  REST 和 HTTP 不一样。

尽管 REST 也旨在使 Web（互联网）更加精简和标准化，但 Roy Fielding 主张更严格地使用 REST 原则。这就是人们尝试开始将 REST 与 Web 进行比较的地方。

Roy Fielding 在他的论文中没有提到任何实现方向——包括任何协议偏好甚至 HTTP。到目前为止，我们一直遵守 REST 的六项指导原则，我们可以将其称为我们的界面 – RESTful。

总结

简而言之，在 REST 架构风格中，数据和功能被视为资源，并使用 统一资源标识符 (URI) 进行访问。

通过使用一组简单、定义明确的操作来对资源进行操作。此外，资源必须与其表示形式分离，以便客户端可以访问各种格式的内容，例如 HTML、XML、纯文本、PDF、JPEG、JSON 等。

客户端和服务器通过使用标准化的接口和协议来交换资源的表示。通常 HTTP 是最常用的协议，但 REST 并不强制要求它。

有关资源的元数据可用并用于控制缓存、检测传输错误、协商适当的表示格式以及执行身份验证或访问控制。

最重要的是，与服务器的每次交互都必须是无状态的。

所有这些原则都有助于 RESTful 应用程序变得简单、轻量级和快速。