REST API 是一种遵循 REST 架构风格设计原则的应用程序编程接口（API）。REST 是“Representational State Transfer”（表述性状态转移）的缩写，它是一套关于如何构建 Web API 的规则和指导方针。
什么是 API？
API（应用程序编程接口）是一组用于构建和集成应用程序软件的定义与协议。它有时被称作信息提供者与信息使用者之间的“契约”——明确规定了消费者（调用方）需要提供什么内容，以及生产者（服务端）需要返回什么内容。例如，一个天气服务的 API 设计可能规定：用户需提供邮政编码，而服务端则返回一个包含两部分的答案：最高温度和最低温度。
换句话说，如果你想与某台计算机或系统交互以获取信息或执行某个功能，API 能帮助你向该系统清晰地表达你的需求，从而让系统理解并完成请求。
你可以将 API 视为用户（或客户端）与他们想要访问的资源或 Web 服务之间的中介。同时，API 也是一种组织在保持安全性、控制权和身份验证的前提下共享资源与信息的方式——明确谁可以访问哪些内容。
使用 API 的另一个优势在于：你无需了解缓存的具体实现细节——比如资源是如何被检索的，或者数据来自哪里。
REST
REST 是一套架构约束（architectural constraints），而非协议或标准。API 开发者可以以多种方式实现 REST。
当客户端通过 RESTful API 发起请求时，它会从服务端接收到所请求资源的“状态表述”（representation of the state）。这种信息（即表述）通常通过 HTTP 协议以多种格式传输，例如 JSON（JavaScript Object Notation）、HTML、XML、Python、PHP 或纯文本。其中，JSON 是最广泛使用的格式，因为尽管其名称中包含“JavaScript”，但它实际上是语言无关的，并且对人类和机器都易于阅读。
另外需要注意的是：在 RESTful API 的 HTTP 请求中，请求头（Headers）和参数（Parameters） 也非常重要，因为它们包含了关于请求元数据的关键信息，如授权凭证、统一资源标识符（URI）、缓存策略、Cookie 等。HTTP 请求和响应各自都有对应的头部信息，其中包含连接详情和状态码。
要被视为 RESTful，一个 API 必须符合以下标准：
- 客户端-服务器架构：由客户端、服务器和资源组成，所有请求均通过 HTTP 进行管理。
- 无状态通信（Stateless）：服务器不会在多个请求之间存储客户端信息；每个请求都是独立且互不关联的。
- 可缓存（Cacheable）：响应数据应标明是否可被缓存，以优化客户端与服务器之间的交互效率。
- 统一接口（Uniform Interface）：组件之间通过标准化形式交换信息。这要求：
- 所请求的资源必须具有唯一标识，并且与发送给客户端的表述形式相分离；
- 客户端可以通过接收到的表述来操作资源，因为该表述包含了足够的操作信息；
- 返回给客户端的消息是自描述的（self-descriptive），即包含足够信息说明客户端应如何处理该消息；
- 支持超文本/超媒体（HATEOAS）：客户端在访问某个资源后，应能通过超链接发现当前可用的所有其他操作。
- 分层系统（Layered System）：将负责安全、负载均衡等功能的各类服务器组织成层级结构，而客户端对此透明无感。
- 按需代码（Code-on-Demand，可选）：服务器可在请求时向客户端发送可执行代码，以扩展客户端的功能。
尽管 REST API 需满足上述约束条件，但它仍比像 SOAP（Simple Object Access Protocol，简单对象访问协议）这样的严格协议更易于使用。SOAP 要求使用 XML 消息格式，并内置了复杂的安全性和事务合规机制，导致其更慢、更笨重。
相比之下，REST 只是一套可根据需要灵活实现的指导原则，因此 REST API 更轻量、更快，并具备更强的可扩展性——特别适合物联网（IoT）和移动应用开发。