您需要了解的 6 种最流行的 API 架构风格（包括优点、缺点和用例）

在本文中，我们将讨论 6 种最流行的 API 架构风格：REST、SOAP、GraphQL、gRPC、WebSocket 和 Webhooks。

API 是软件之间相互通信和共享数据的方式。设计和构建 API 的方法多种多样。让我们来看看六种最流行的 API 架构风格及其优缺点和用例。

休息

REST 是一种使用 Web 标准和地址来处理服务器上数据的方式。它非常流行，易于实现，并且使用 HTTP 方法。您日常使用的大多数 Web 服务（例如 Twitter 或 YouTube）都由 Restful API 提供支持。例如，客户端可以使用 GET 来获取数据，使用 POST 来创建新数据，使用 PUT 来更改数据，或使用 DELETE 来删除数据。数据通常采用 JSON 或 XML 等格式。

优点

• 它简单且易于使用和理解。

• 它遵循网络规则并使用现有的标准和协议。

• 它速度很快，可以处理许多请求，因为它支持缓存和无状态。

• 它非常灵活，可以使用不同的格式和媒体类型。

缺点

• 它没有明确的合同或模式，这会导致其不清楚和不一致。

• 它不支持复杂的查询或操作，这会导致它需要很多请求并获取过多或过少的数据。

• 它不能很好地处理错误或异常，因为它使用的 HTTP 状态代码并不总是清晰或正确的。

用法

REST 适用于以下情况：

• 数据模型简单、稳定。

• 客户端和服务器彼此不依赖。

• 速度和可扩展性很重要。

肥皂

SOAP 是一种使用 XML 消息和预定义契约在应用程序之间交换信息的方式。它拥有清晰而严格的契约，支持复杂的查询和操作，但其本身复杂、冗长，并且不具备可扩展性和性能。

优点

• 它具有明确而严格的合同，可确保互操作性和兼容性。

• 它支持复杂的查询和操作，例如交易、安全或身份验证。

• 它可以很好地处理错误和异常，因为它使用提供详细信息的 SOAP 故障。

缺点

• 它的使用和理解非常复杂且冗长。

• 它不遵循网络原则并增加了现有协议的开销。

• 它不具有可扩展性或性能，因为它不支持缓存或无状态。

• 它不灵活或不可扩展，因为任何修改都需要更改合同。

用法

SOAP 适用于以下场景：

• 数据模型复杂且动态。

• 客户端和服务器紧密耦合且相互依赖。

• 它广泛用于金融服务和支付网关，安全性和可靠性是关键

GraphQL

GraphQL 不仅是一种架构风格，也是一种查询语言，它允许客户端根据需要请求特定数据。这意味着不再出现数据过度获取或获取不足的情况。您可以精确地请求所需的数据。这可以提高网络通信效率并加快响应速度。Facebook 开发了 GraphQL，旨在为其数十亿用户提供高效精准的数据。现在，它已被 GitHub 和 Shopify 等公司所采用。其灵活性和高效性使其成为具有复杂数据需求的应用程序的理想选择。它还支持通过突变来更改数据，以及通过订阅来在数据发生变化时获取实时更新。

优点

• 它适用于任何服务器语言或框架，因为它使用自己的模式定义语言。

• 它有一个单一端点，这使得它比 REST 更高效，因为 REST 可能需要多个请求才能获取足够的数据。

• 它是强类型的，确保客户端和服务器之间的数据一致且兼容。

• 它让客户端只获取他们需要的数据，从而避免数据过度获取或获取不足。

缺点

• 它很复杂，难以使用和理解，因为它需要学习新的语法和逻辑。

• 它默认不支持缓存，这会影响性能和可扩展性。

• 它不能很好地处理错误，因为它总是返回 HTTP 200 状态代码，即使 GraphQL 层出现错误。

用法

GraphQL 适用于以下情况：

• 该数据模型复杂且动态，因为它可以处理嵌套和关系数据。

• 客户端和服务器彼此不依赖，因为它允许客户端定义自己的数据需求。

• 带宽和性能很重要，因为它减少了传输的数据量。

gRPC

gRPC 是一种现代的、高性能的协议缓冲区。它是微服务架构的首选，像 Netflix 这样的公司也使用 gRPC 来处理其庞大的服务间通信。但是，如果您使用的是浏览器客户端，由于浏览器支持有限，gRPC 可能会带来一些挑战。

优点

• 它具有明确而严格的契约，确保服务之间的互操作性和兼容性。

• 它支持复杂的查询和操作，例如流式传输、双向通信、身份验证或加密。

• 它快速而高效，因为它使用二进制格式和 HTTP/2 功能来减少延迟和带宽。

缺点

• 它很复杂，难以使用和理解，因为它需要生成和编译协议缓冲区文件。

• 它不遵循网络原则，因为它使用与标准网络工具或浏览器不兼容的自定义标头和方法。

用法

gRPC 适用于以下情况：

• 该数据模型复杂且动态，因为它可以处理结构化和非结构化数据。

• 这些服务相互依赖，因为它允许服务直接调用彼此的方法。

• 速度和效率很重要，因为它可以最大限度地减少开销并最大限度地提高吞吐量。

WebSocket

WebSocket 的核心在于实时、双向、持久的连接。它非常适合实时聊天应用和实时游戏，因为低延迟的数据交换对这些应用至关重要。

优点

• 它比 HTTP 更快、更高效，因为它使用单个连接并且不需要每条消息的标头或 cookie。

• 它可以通过同一个连接发送和接收不同类型的消息，例如文本、二进制或流数据。

• 它可以将数据从服务器推送到客户端而无需等待请求，从而实现实时和事件驱动的通信。

缺点

• 一些不理解 WebSocket 协议或升级标头的旧浏览器或代理不支持它。

• 默认情况下它并不安全，因为除非它们使用与HTTPwss://类似的方案，否则它们不使用加密或身份验证。https://

• 它不存储有关连接或两侧消息的任何信息，这意味着它们不是有状态的。

用法

WebSocket 适用于以下情况：

• Web 应用程序需要快速且交互式的数据交换，例如聊天、游戏或流媒体。

• Web 应用程序需要双向和多路复用通信，双方可以同时发送和接收不同类型的多条消息。

• Web 应用程序需要实时和事件驱动的通信，其中服务器可以向客户端发送数据而无需等待请求。

Webhook

Webhook 是服务器在事件发生时向客户端发送消息的一种方式。它们使用 HTTP 回调或 POST 请求来传递包含事件信息的有效负载。客户端通过提供可以接收有效负载的 URL 向服务器注册其 Webhook。Webhook 的核心是事件驱动、HTTP 回调和异步操作。

优点

• 它使用标准 HTTP 方法和格式，简单且易于使用和理解。

• 它遵循网络原则，利用现有的标准和协议。

• 它具有可扩展性和高性能，因为它支持异步通信，无需轮询或等待。

缺点

• 它没有明确或严格的合同，这可能导致服务器和客户端之间的不一致和模糊性。

• 它不支持复杂的查询或操作，它只发送单向通知，无需确认或反馈。

• 它不能很好地处理错误，在发生故障时它不提供重试或确认。

用法

Webhook 适用于以下情况：

• 事件驱动通知（每当推送新的提交时，GitHub 使用 webhook 通知您的其他系统。）

• 数据模型简单、稳定，可以处理基本类型和字段。

• 服务器和客户端彼此不依赖，因为它们不需要直接通信或协调。

• 性能和可扩展性很重要，因为它们可以减少通信的负载和延迟。

这是最终的汇总表

示例 API 架构风格

参考

• 六大最流行的 API 架构风格 - ByteByteGo

• https://blog.bytebytego.com/p/ep49-api-architectural-styles

• https://www.postman.com/state-of-api/api-technologies/#api-technologies

如果您正在使用Medium，请支持我并关注我，获取更多有趣的文章。Medium简介

订阅我的新闻通讯：

如果您准备订阅，只需点击以下链接：

订阅我的新闻通讯

点击链接，您将跳转至新闻通讯页面，轻松订阅，并定期接收直接发送到您邮箱的更新。不要错过软件开发领域的最新趋势和专家分析。

关注我，了解最新、最有趣的文章。

如果本指南对您和您的团队有帮助，请与其他人分享！