API
API 由一组定义和协议组合而成，可用于构建和集成应用软件。有时我们可以把它们当做信息提供者和信息用户之间的合同——建立消费者（呼叫）所需的内容和制作者（响应）要求的内容。例如，天气服务的 API 可指定用户提供邮编，制作者回复的答案由两部分组成，第一部分是最高温度，第二部分是最低温度。
REST
REST 是一组架构规范，并非协议或标准。API 开发人员可以采用各种方式实施 REST。
当客户端通过 RESTful API 提出请求时，它会将资源状态表述传递给请求者或终端。该信息或表述通过 HTTP 以下列某种格式传输：JSON（Javascript 对象表示法）、HTML、XLT、Python、PHP 或纯文本。JSON 是最常用的编程语言，尽管它的名字英文原意为“JavaScript 对象表示法”，但它适用于各种语言，并且人和机器都能读。
还有一些需要注意的地方：头和参数在 RESTful API HTTP 请求的 HTTP 方法中也很重要，因为其中包含了请求的元数据、授权、统一资源标识符（URI）、缓存、cookie 等重要标识信息。有请求头和响应头，每个头都有自己的 HTTP 连接信息和状态码。
RESTful API
- 客户端-服务器架构由客户端、服务器和资源组成，并且通过 HTTP 管理请求。
- 无状态客户端-服务器通信，即 get 请求间隔期间，不会存储任何客户端信息，并且每个请求都是独立的，互不关联。
- 可缓存性数据：可简化客户端-服务器交互。
组件间的统一接口：使信息以标准形式传输。这要求：
- 所请求的资源可识别并与发送给客户端的表述分离开。
- 客户端可通过接收的表述操作资源，因为表述包含操作所需的充足信息。
- 返回给客户端的自描述消息包含充足的信息，能够指明客户端应该如何处理所收到的信息。
- 超文本/超媒体可用，是指在访问资源后，客户端应能够使用超链接查找其当前可采取的所有其他操作。
- 组织各种类型服务器（负责安全性、负载平衡等的服务器）的分层系统会参与将请求的信息检索到对客户端不可见的层次结构中。
- 按需编码（可选）：能够根据请求将可执行代码从服务器发送到客户端，从而扩展客户端功能。
虽然 REST API 需要遵循这些标准，但是仍比遵循规定的协议更容易，如 SOAP（简单对象访问协议），该协议具有 XML 消息传递、内置安全性和事务合规性等具体要求，因此速度较慢、结构繁重。
相比之下，REST 则是一组可按需实施的准则，使 REST API 速度更快、更轻，可扩展性更高，非常适合物联网（IoT）和移动应用开发。
SOAP（简单对象访问协议）
SOAP 是一项标准协议，其最初的设计意图是让使用不同语言且在不同平台上构建的应用之间进行通信。由于 SOAP 是一项协议，因此它会施加一些内置规则，从而增加复杂性和开销，并可导致页面加载时间延长。但是，这些标准还提供了内置合规性，使其更适合企业应用。内置合规性标准包括安全性、原子性、一致性、隔离性和持久性（ACID），这是一组旨在确保数据库事务可靠性的属性。
常见的 Web 服务规范包括：
- Web 服务安全性（WS 安全性）：通过叫做"令牌"的唯一标识符，实现消息安全防护和传输方式的标准化。
- WS-ReliableMessaging：标准化了在不可靠的 IT 基础架构间传输消息的错误处理方式。
- Web 服务寻址（WS 寻址）：将路由信息打包为 SOAP 标头中的元数据，而不是在网络深处维护此类信息。
- Web 服务描述语言（WSDL）：描述 Web 服务的功能以及该服务的工作起点和终点。
当有数据请求发送给 SOAP API 时，可以通过任何应用层协议来处理该请求：HTTP（针对 Web 浏览器）、SMTP（针对电子邮件）、TCP 等等。但是，一旦收到请求，返回的 SOAP 消息必须以 XML 文档（一种人机均可读的标记语言）的形式返回。浏览器无法缓存已完成的 SOAP API 请求，因此如果不重新发送给 API，之后便无法访问该请求。
SOAP VS REST
许多传统系统可能仍会遵循 SOAP 准则，而在基于 Web 的场景中，REST 常常被视为一种后来居上的替代方法。REST 是一组可灵活实施的准则，而 SOAP 则是具有特定要求（例如 XML 消息传递）的协议。
REST API 属于轻量级 API，因此非常适合较新的环境，例如物联网（IoT）、移动应用开发和无服务器计算。SOAP Web 服务可提供符合许多企业需求的内置安全性和事务合规性，但同时也会让它们变得结构繁重。此外，许多公共 API（例如 Google Maps API）都遵循 REST 准则。
JSON API
JSON 或 JavaScript 对象表示法是一种编码方案，旨在消除每个应用程序与以定义方式通信的服务器通信的临时代码的需要。JSON API 模块公开了数据存储和数据结构的实现，例如实体类型、包和字段。
gRPC
gRPC 是一个高性能、开源的通用 RPC 框架
RPC 代表远程过程调用，关于 g 代表什么的争论一直存在。RPC 是一种协议，允许程序执行位于另一台计算机上的另一个程序的过程。最大的优势是开发人员不需要编写远程交互的细节代码。远程过程像任何其他函数一样被调用。但是客户端和服务器可以用不同的语言进行编码。
GraphQL
GraphQL 是一种用于 API（应用程序编程接口）的查询语言和运行时系统。它旨在为客户端从服务器请求数据提供一种灵活高效的方式，并且经常用作 REST（具象状态传输）API 的替代方案。
GraphQL 的主要特性之一是它能够准确指定所需的数据，而不是从端点接收一组固定的数据。这允许客户端仅请求他们需要的数据，并且减少了需要通过网络传输的数据量。
GraphQL 还提供了一种方法来定义从服务器返回的数据的结构，允许客户端以可预测和灵活的方式请求数据。这使得构建和维护依赖于服务器数据的客户端应用程序变得更加容易。
认证（Authentication）
API 身份验证过程使用身份验证协议验证尝试建立连接的客户端的身份。该协议以纯文本或加密形式从请求连接到远程访问服务器的远程客户端发送凭据。服务器然后知道它是否可以授予对该远程客户端的访问权限。
其它
HATEOAS
HATEOAS 是Hypermedia As The Engine Of Application State的首字母缩写词，它的概念是当通过 RESTful API 发送信息时，收到的文档应包含客户端解析和使用数据所需的一切，即它们不必联系文档中未明确提及的任何其他端点
Open API Specs
Open API Specs（开放API规范） (OAS) 定义了一个标准的、与语言无关的 RESTful API 接口，它允许人类和计算机发现和理解服务的功能，而无需访问源代码、文档或通过网络流量检查。正确定义后，消费者可以使用最少量的实现逻辑来理解远程服务并与之交互。
然后，文档生成工具可以使用 OpenAPI 定义来显示 API，代码生成工具可以使用各种编程语言、测试工具和许多其他用例来生成服务器和客户端。
