随着 Web API 的不断普及，相应的协议规范也随之产生了，从而推动了信息交换的标准化：简单对象访问协议，简称 SOAP。使用 SOAP 设计的 API 会使用 XML 格式来收发消息，并通过 HTTP 或 SMTP 来接收请求。使用 SOAP 时，在不同环境中运行的应用或使用不同语言编写的应用能够更加轻松地共享信息。
相关的规范还有一个，即表述性状态传递（REST）。遵循 REST 架构约束的 Web API 被称为 RESTful API。REST 与 SOAP 有着根本区别：SOAP 是一种协议，而 REST 是一种架构风格。这意味着 RESTful Web API 没有官方标准。正如 Roy Fielding 在论文“Architectural Styles and the Design of Network-based Software Architectures”（架构模式以及基于网络的软件架构的设计）中定义的那样，只要 API 符合 RESTful 系统的 6 个导向性约束，就算作 RESTful API：
客户端/服务器架构：REST 架构由客户端、服务器和资源构成，通过 HTTP 来处理请求。无状态：请求所经过的服务器上不会存储任何客户端内容。与会话状态相关的信息会存储在客户端上。可缓存性：通过缓存，可免去客户端与服务器之间的某些交互。分层系统：客户机与服务器之间的交互可以通过额外的层来进行调解。这些层可以提供额外的功能，如负载均衡、共享缓存或安全防护。按需代码（可选）：服务器可通过传输可执行代码来扩展客户端的功能。统一接口：这项约束是 RESTful API 的设计核心，共涵盖 4 个层面：识别请求中的资源：请求中的资源会被识别，并与返回给客户端的表示内容分离开来。通过不同的表示内容来操纵资源：客户端会收到表示不同资源的文件。这些表示内容必须提供足够的信息，以便执行修改或删除操作。自描述消息：返回给客户端的每个消息都包含充足的信息，用于指明客户端应该如何处理所收到的信息。将超媒体作为应用状态的引擎：在访问某个资源后，REST 客户端应该能够通过超链接来发现当前可用的所有其他操作。虽然看似有很多约束需要遵循，但是这些约束遵循起来要比遵循规定的协议容易得多。因此，RESTful API 现在变得比 SOAP 更为普及。
近年来，OpenAPI 规范已发展成为定义 REST API 的通用标准。OpenAPI 为开发人员提供了一种与语言无关的方式来构建 REST API 接口，从而最大程度减少不确定的因素，让用户安心工作。
另一个新兴的 API 标准是 GraphQL，这是一种可替代 REST 的查询语言和服务器端运行时。GraphQL 可优先让客户端准确地获得所需的数据，没有任何冗多余。作为 REST 的替代方案，GraphQL 允许开发人员构建相应的请求，从而通过单个 API 调用从多个数据源中提取数据。
详细了解 SOAP 和 REST