REST API 是一种应用编程接口 (API)，遵循表征状态转移 (REST) 模型，支持两个系统（客户端和服务器）之间通过互联网等网络进行数据表示和通信。REST API 支持在内部和第三方应用之间执行信息交换，并允许企业将多个端点集成到其应用生态系统中。
注：严格来说，REST 指的是模型，而不是作为形容词来描述某 API 遵循该模型，后者的专有名词是“RESTful API”。但“REST API”是更常见的用法，因此本文也使用了这一用法。
API 是什么？
API 是一组定义、规则和协议，用于规范信息使用者（客户端）和信息提供者（服务器）之间的数据交换。换言之，API 是访问信息（即在线和 Web 应用提供的数据资源）的用户（人或软件）之间的一种通信方式。当开发人员为一款应用创建 API 并将其暴露到互联网上时，其他应用就可以以编程方式与该应用通信。
API 能够确保信息的可复用性和可访问性，从而帮助企业做出数据驱动型决策，并有助于开发人员简化工作。开发人员可通过调用现有应用的 API 中的函数，将功能集成到其应用中，而不必浪费时间来复制现有应用的功能。
如欲进一步了解不同的 API 用法，请参见《什么是 API 互联》
什么是 REST？
如前所述，REST 是指“表征状态转移（representational state transfer）”，是由计算机科学家 Roy Fielding 于 2000 年创建的一种架构风格。REST 为开发人员提供了灵活性，因而非常适合连接微服务架构中的应用。
REST 定义了以下 6 个约束条件，应用和 API 必须遵守这些条件才能被视为 RESTful：
有关这些约束条件的更多信息，请参见维基百科。
统一接口
统一接口可简化整个系统架构，并提高交互可视性。它还有具体的要求说明，以确保以标准形式传输信息。
以下 4 个约束条件可确保 REST 接口的统一：
- 每个资源都有一个唯一标识符（例如 URI），并且消息中的资源表示（representation）与服务器的内部表示不同
- 资源表示为客户端修改或删除资源状态提供了足够的信息
- 每条消息都包含足够的信息来描述资源处理方式
- 服务器使用超链接向客户端告知可用资源，因此客户端无需了解服务器内部信息
客户端-服务器
“客户端-服务器”架构由客户端（client）、服务器（sever）和资源（resources）组成。将用户界面（由客户端控制）与数据存储（由服务器控制）分离开来，意味着客户端和服务器组件可自主演进。它还简化了客户端用户界面在多个平台上的可移植性和服务器的可扩展性。
在互联网上，“客户端-服务器”的交互通过 HTTP 实现。
无状态
在“客户端-服务器”通信中，“无状态”意味着服务器不会存储有关客户端或与客户端所建会话（session）的任何信息。客户端必须确保服务器能够独立地理解每条消息中与会话相关信息的表示（representation），且无需从之前的消息中获取任何上下文。这有助于减轻服务器负载，从而提高大容量应用的性能。
分层系统
客户端不需要知道（通常也无法判断）它们是直接连接到服务器还是连接到反向代理或负载均衡器等中介。中介服务器有助于提高可扩展性，并可用于处理安全问题，这样服务器就只负责处理业务逻辑。
可缓存性
HTTP 客户端和中介组件可以缓存服务器响应，以减少服务器上的负载，并提高向最终用户传递数据的速度。服务器必须指明响应（response）是可缓存的还是不可缓存的，后者可确保对后续最终用户请求的响应是正确且最新的（而非可能“过期”的数据）。由于客户端访问资源的 URL 是唯一标识符，因此客户端能够从“资源”的层面确定缓存内容。
按需编码
按需编码是指服务器可以发送可执行代码以暂时扩展或自定义客户端功能，而无需客户端自己实现这些功能。“按需编码”这一约束条件不是必需的。
什么是资源？
REST 中最重要的数据表示或抽象是“资源（resource）”。REST 资源可以是任何类型的抽象信息，包括数字文档和非数字对象。资源在任何特定时间的状态称为“资源表示（resource representation）”。
资源表示包括以下三个部分：
- 数据
- 元数据
- 超媒体链
REST API 由一组可通过唯一 URL 访问的互联资源（或其“资源模型（resource model）”）组成。客户端可以通过链接到响应中的相关资源和 URI 来实现灵活的功能。通常，对 REST API 的请求以 HTTP GET 请求的形式发送；服务器通常将其响应格式化为 JSON。
下列 HTTP 请求方法用于以指定方式处理资源：
GET– 加载资源POST– 创建新资源PUT– 修改现有资源DELETE– 删除资源
资源标识符
在 REST 架构风格中，资源标识符（resource identifier）唯一地指定了参与“客户端-服务器”交互的每个资源。
超媒体
“媒体类型（media type）”或数据格式表示（representation of data format）定义了应如何处理资源。在 REST API 中，所有媒体类型都基于 JSON，并均为超媒体（有时称为“超文本”，但与超文本略有不同）。“超媒体”是指带有其他媒体链接的任何内容。超媒体即应用状态引擎 (Hypermedia as the Engine of Application State，即 HATEOAS) 是 REST 架构的独特之处。
注：Roy Fielding 指出，要将 API 视为 REST API，则必须使用超媒体。然而，如今许多 API 设计人员经常将其 API 称为 “REST[ful]”，尽管他们不使用超媒体/超文本。
自描述
资源表示旨在实现自描述（self-descriptive），这意味着 API 在其自己的上下文中进行自我表述。借助自描述表示，客户端无需知道资源所属类别，而是根据与资源相关的媒体类型进行操作。
REST API 的优势
如今，大多数企业都使用内部开发的 API 和第三方 API 在提供基本功能、创新功能和关键功能的应用之间进行通信。这些 API 大多是 REST API，因为 REST 规定的特定通信标准支持执行安全、高效和可靠的信息交换。REST API 也可与任何协议配合使用。
REST API 也具有安全性，因为 RESTful Web 服务会在发送响应之前对请求进行身份验证。为了验证用户身份，REST API 使用 HTTP 身份验证（同时使用 Basic 令牌 和 Bearer 令牌）、API 密钥及 Oauth 进行登录访问。
REST API 的其他优势包括：
- 系统可扩展性 — REST API 可以高效扩展，因为 REST 优化了客户端和服务器之间的交互。RESTful 无状态约束条件可减轻服务器负载，因为服务器不必保存来自先前请求或有关先前请求的信息。 此外，可缓存性能够减少可能造成瓶颈的“客户端-服务器”交互的数量。这有助于构建可扩展的高性能 API。
- 开发灵活性 — 许多企业应用需要与内部或第三方 API 进行通信。RESTful Web 服务支持客户端和服务器之间分离开来，以便两者独立演进。
- 技术独立性 — REST API 独立于应用所用的编程语言和框架。客户端和服务器应用无需使用相同的语言或框架，这些语言或框架可在不影响 API 设计或通信流程的情况下进行更改。
REST API 与 GraphQL
REST 仍是用于连接客户端和服务器应用的最常见的架构，而 GraphQL（由 Facebook 于 2012 年开发，在 2015 年实现开源）则是 REST 的替代方案。 GraphQL API 比 REST API 更高效，因为所需的所有数据都在单个请求中以标准化的形式进行请求，但 REST 仍在一些领域表现出色。GraphQL 的学习难度较大，而且可缓存性远不如 REST。此外，应用通常由资源驱动，无需使用 GraphQL 等查询语言。也就是说，每种模型都有其优缺点，企业可以兼而用之。
NGINX 如何助一臂之力？
REST API 的灵活性无疑是一大优势。但过高的灵活性也可能导致设计出的 API 速度缓慢或失效，因此许多开发人员选择使用 OpenAPI 规范发布、管理并生成 API 文档。
API Connectivity Manager 是 F5 NGINX Management Suite 的一部分，支持 REST API 的 OpenAPI 规范。 API Connectivity Manager 在设计时充分考虑了 API 开发人员体验。这款轻量级、云原生 API 管理解决方案可无缝集成，支持将 API 发布到开发人员门户和 API 网关。
立即开启 NGINX Management Suite 30 天免费试用，包括 API Connectivity Manager 和 Instance Manager。
