什么是REST

REST是REpresentational State Transfer的缩写，也是分布式超媒体系统的架构风格。2000年，罗伊·菲尔丁在他著名的论文中首次提出了这一观点。从那时起，它已成为构建基于Web的API（应用程序编程接口）的最广泛使用的方法之一。

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

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

符合REST架构风格的Web API（或Web服务）称为REST API （或RESTful API）

一、REST的六大指导原则

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

统一接口

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

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

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

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

客户端-服务器

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

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

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

无状态的

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

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

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

可缓存的

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

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

层状体系

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

一个外行的分层系统的例子是MVC模式。MVC模式允许明确的关注点分离，使开发、维护、和扩展应用程序变得更容易。

按需编码（可选的）

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

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

二、什么是资源

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

资源在任何特性时间的状态称为资源表示。资源表示形式包括：

数据
描述数据的元数据
以及可以帮助客户端转换到下一个期望状态的超媒体链接。

REST API 由相互链接的资源组成。这组资源称为REST API的资源模型。

资源标识符

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

超媒体

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

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

超文本（或超媒体）意味着信息和空间的同时呈现，使得信息称为用户（或自动机）获得选择和选择操作的启示。
请记住，超文本在浏览器上不需要是HTML（或XML或JSON）。当机器理解数据格式和关系类型时，他们可以遵循链接。
—— Roy Fielding

自描述

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

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

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

媒体类型与资源方法GET/PUT/POST/DELETE...没有关系，除了某些媒体类型元素将定义一个类似于“带有 href 属性的锚元素创建一个超文本链接，当被选中时，在对应于CDATA编码的 herf 属性的URI上调用检索请求（GET）”的过程模型。

例如

考虑下面的REST资源，它表示一个博客文章，其中包含指向基于HTTP的REST API中相关资源的链接。这包含了关于博客文章的必要信息，以及到相关资源（如作者和评论）的超媒体链接。客户可以通过这些链接来发现其他信息或执行操作。

{
  "id": 123,
  "title": "What is REST",
  "content": "REST is an architectural style for building web services...",
  "published_at": "2023-11-04T14:30:00Z",
  "author": {
    "id": 456,
    "name": "John Doe",
    "profile_url": "https://example.com/authors/456"
  },
  "comments": {
    "count": 5,
    "comments_url": "https://example.com/posts/123/comments"
  },
  "self": {
    "link": "https://example.com/posts/123"
  }
}

三、资源方法

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

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

例如，如果我们决定应用程序API将使用HTTP POST来更新资源-而不是更常见的HTTP PUT -这是正确的。尽管如此，应用程序接口将是RESTful的。

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

我们应该输入一个REST API，除了初始URI（书签）和一组适合目标受众的标准化媒体类型（即，期望被可能使用该API的任何客户端理解）。

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

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

四、REST和HTTP不一样

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

REST != HTTP

虽然REST也打算使Web（互联网）更加精简和标准，但Roy Fielding主张更严格地使用REST原则。这就是人们试图将REST与Web进行比较的地方。

罗伊·菲尔丁在他的论文中没有提到任何实现方向-包括任何协议偏好甚至HTTP。只要我们尊重REST的六个指导原则，我们就可以称我们的接口为RESTful。

总结

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

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

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

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

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

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

Happy Learning !!

References:

翻译自restfulapi.net