什么是 REST API？

REST，如上所述，代表表述性状态转移，是由计算机科学家 Roy Fielding 于 2000 年创建的一种架构风格。 REST 为开发人员提供了灵活性，使其成为连接微服务架构中applications的理想选择。

REST 定义了六个约束，应用程序和 API 必须遵循这些约束才能被视为 RESTful：

• 统一接口
• 客户端-服务器架构
• 无国籍
• 分层系统
• 缓存能力
• 按需编码

您可以在Wikipedia上了解有关这些限制的更多信息。

统一接口

统一的界面简化了整体系统架构，提高了交互的可见性。 它还有具体要求以确保信息以标准形式传输。

四个约束使得 REST 接口能够统一：

• 每个资源都有一个唯一的标识符，例如 URI，并且消息中资源的表示与服务器的内部表示是分开的
• 资源表示包含足够的信息，以便客户端修改或删除资源的状态
• 每条消息都包含足够的信息来描述如何处理它
• 服务器使用超链接通知客户端可用资源，从而无需客户端了解服务器内部情况

客户端-服务器

客户端-服务器架构由客户端、服务器和资源组成。 将用户界面（由客户端控制）与数据存储（由服务器控制）分离意味着客户端和服务器组件可以自主发展。 它还简化了跨多个平台的客户端用户界面的可移植性和服务器的可扩展性。

在互联网上，客户端和服务器之间的交互通过HTTP 进行。

无国籍

在客户端-服务器通信中，无状态意味着服务器不存储有关客户端或与其建立的会话的任何信息。 客户端在每条消息中对会话相关信息的表示必须使服务器能够单独理解它，而无需来自先前消息的任何上下文。 这减少了服务器负载，提高了大容量applications的性能。

分层系统

客户端不需要知道（通常也无法分辨）它们是直接连接到服务器还是连接到反向代理或负载平衡器等中介。 中间服务器有助于提高可扩展性，并可用于处理安全性，以便服务器只负责业务逻辑。

可缓存性

HTTP 客户端和中介可以缓存服务器响应以减少服务器的负载并提高向最终用户传递数据的速度。 服务器必须指示响应是否可缓存或不可缓存，后者确保对后续最终用户请求的响应是正确且最新的（不会是“陈旧的”）。 由于客户端通过 URL（唯一标识符）访问资源，因此客户端可以确定在资源级别缓存什么。

按需编码

按需代码意味着服务器可以发送可执行代码来临时扩展或定制客户端功能，从而无需客户端本身实现该功能。 按需代码约束是可选的。

REST 中最重要的数据表示或抽象是资源。 REST 资源可以是任何类型的抽象信息——从数字文档到非数字对象。 资源在任意给定时间的状态称为资源表示。

资源表示由三部分组成：

• 数据
• 元数据
• 超媒体链接

REST API 由一组相互链接的资源（或其资源模型）组成，这些资源可通过唯一的 URI 访问。 客户端可以通过链接到响应内的相关资源和 URI 来实现灵活的功能。 一般来说，对 REST API 的请求以 HTTP GET 请求的形式发送；服务器通常将其响应格式化为 JSON。

以下 HTTP 请求方法用于以指示的方式对资源采取行动：

• GET——加载资源
• POST – 创建新资源
• PUT——修改现有资源
• 删除——删除资源

资源标识符

在 REST 架构风格中，资源标识符唯一地指定了涉及客户端-服务器交互的每个资源。

超媒体

“媒体类型”或数据格式的表示定义了如何处理资源。 在 REST API 中，所有媒体类型都基于 JSON 并且都是超媒体（有时也称为超文本，但略有不同）。 超媒体是任何带有指向其他媒体的链接的内容。 超媒体作为application程序状态引擎 (HATEOAS) 使得 REST 架构独一无二。

笔记： 根据 Roy Fielding 的说法，要将 API 视为 REST API，它必须使用超媒体。 然而，当今许多 API 设计师虽然不使用超媒体/超文本，但经常将他们的 API 称为“REST[ful]”作为一个流行词。

自我描述

资源表示旨在具有自描述性，这意味着 API 可以在其自身上下文中让人理解。 通过自描述表示，客户端不需要知道资源属于哪个类别，而是根据与资源关联的媒体类型采取行动。

如今，大多数企业使用内部开发和第三方 API 来实现应用程序之间的通信，这些应用程序提供基本、创新和关键功能。 这些 API 大部分都是 REST API，因为 REST 规定的特定通信标准能够实现安全、高效、可靠的信息交换。 REST API 也可以与任何协议一起使用。

REST API 也是安全的，因为 RESTful Web 服务在发送响应之前会对请求进行身份验证。 为了验证用户身份，REST API 采用 HTTP 身份验证（基本身份验证和Bearer Token 身份验证）、API 密钥和 OAuth 进行登录访问。

REST API 的其他好处包括：

• 系统可扩展性——REST API 可以有效扩展，因为 REST 优化了客户端和服务器之间的交互。 RESTful无状态约束减少了服务器负载，因为服务器不必保存来自或有关以前请求的信息。 此外，可缓存性减少了可能造成瓶颈的客户端 - 服务器交互的次数。 这会产生可扩展、高性能的 API。
• 开发人员的灵活性——许多企业applications需要与内部或第三方 API 进行通信。 RESTful Web 服务支持客户端和服务器之间的分离，使得每个客户端和服务器能够独立发展。
• 技术独立性——REST API 独立于开发相应应用程序的编程语言和框架。 客户端和服务器应用程序不需要共享语言或框架，并且这些可以在不影响 API 设计或通信过程的情况下发生变化。

虽然 REST 仍然是连接客户端和服务器applications最流行的架构，但GraphQL （由 Facebook 于 2012 年开发，并于 2015 年开源）被设计为 REST 的替代方案。 GraphQL API 比 REST API 更高效，因为所需的所有数据都是在单个请求中以标准化形式请求的，但在某些领域 REST 仍表现出色。 GraphQL 的学习曲线比较陡峭，并且可缓存性远不如 REST。 此外，applications通常由资源驱动，不需要像 GraphQL 这样的查询语言。 也就是说，每种模型都有其优点和缺点，组织可以选择同时使用两者。