REST API 的 7 种替代方案

表述性状态传递（REST）是一种构建网络服务的架构风格和协议。它是设计网络应用程序编程接口（API）的一种流行方法，因为它强调可扩展性、简单性和可修改性。

与管理简单对象访问协议（SOAP）或可扩展标记语言远程过程调用（XML-RPC）等 API 协议的严格框架不同，REST 协议历来被用来简化 API 的开发过程，因为它们几乎可以使用任何编程语言构建，并支持各种数据格式。

然而，一些 REST 替代方案的出现正在成为未来十年 API 开发的新热点。这一趋势包括其他协议、模式和技术，如事件驱动 API、GraphQL 和 gRPC。随着这些协议的成熟和被更广泛地接受，API 开发人员必须了解如何在各种平台上部署 REST 替代方案。

让我们来探讨一下是什么让这些 REST 替代方案如此受欢迎，以及支持它们在现场使用的最常见用例。

为什么 REST 替代方案越来越受欢迎？

RESTful APIs之所以流行，是因为它们灵活、易懂，而且兼容任何支持超文本传输协议（HTTP）的编程语言或平台。它们还非常适合构建可扩展的分布式系统，因为它们可以利用 HTTP 的缓存和负载平衡功能。

REST 优先考虑通过资源和代表数据的统一资源标识符（URI）来实现轻松修改。这意味着开发人员可以在不破坏现有客户端应用程序的情况下更改 API 结构。

那么，开发人员为什么还要使用其他方法呢？有几个令人信服的理由：

不断发展的复杂性。REST API 在设计上克服了 SOAP 等早期 API 协议的复杂性，但随着端点和资源数量的增加，其维护工作也变得具有挑战性。随着时间的推移，开发人员很难理解和修改 API。

性能。对于某些用例，REST API 具有可扩展性，可以处理大量请求。不过，实时或低延迟应用可能有更好的选择，因为它们依赖于多个往返请求来检索数据。

不断变化的数据要求。REST API 可能需要进行重大更改，以支持新的用例或数据结构，从而导致版本和兼容性问题，并增加复杂性和开发时间。

特定用例要求。在一些特定用例中，如实时数据流或低功耗物联网（IoT）设备（如上所述），其他协议可能比 REST 协议更适合。

开发人员的偏好。开发人员可能更喜欢使用其他协议，因为他们更熟悉这些协议，或者这些协议具有 REST 所不具备的特定功能或优势。

REST API 的替代方案

以下是您需要了解的七种 REST 替代方案：

GraphQL

GraphQL 是一种用于 API 的运行时和查询语言，它允许客户只请求和接收所需的数据，因此比 REST 更为高效。使用 GraphQL，客户可以指定他们所需的确切数据，并在单个请求中获得这些数据，而不是像 REST 那样向不同的端点发出多个请求。对于具有复杂和不断变化的数据需求的数据驱动型应用程序来说，这是一个不错的选择。

对于需要严格数据验证的应用程序、需要支持各种客户端的应用程序或社交媒体等面向用户的应用程序来说，它可能不是最佳选择。不过，在需要灵活、高效的数据检索和操作的情况下，它仍然是 REST 的绝佳替代选择。对于具有复杂数据模型的应用程序或连接能力有限的移动应用程序来说，这一点尤为重要。

gRPC

gRPC 是谷歌开发的用于构建 RPC API 的开源框架。它允许开发人员使用多种编程语言定义服务接口并生成客户端和服务器代码。gRPC 使用协议缓冲区和语言无关的数据序列化格式来实现高效的数据传输，是高性能应用程序的理想选择。

对于大量数据操作或需要支持各种客户端的应用程序来说，gRPC 可能不是最佳选择。不过，gRPC 以高性能和低开销著称，对于需要在服务间进行快速高效通信的应用程序来说，它是一个不错的选择。

WebSockets

WebSocket 协议可实现客户端与服务器之间的双向实时通信。与基于请求/响应的 REST 不同，WebSockets 允许服务器在数据可用时立即推送给客户端，因此非常适合需要实时更新的应用程序，如聊天应用程序和在线游戏。

对于需要复杂数据操作的应用程序或需要考虑可扩展性的应用程序来说，WebSockets 可能不是最佳选择。不过，由于客户端和服务器之间的全双工持久连接，WebSockets 在需要实时通信和低延迟的应用中大放异彩。REST 使用效率较低的请求/响应模型。

MQTT

MQTT 是专为物联网设备设计的轻量级开源消息传输协议。它是一种数据包小、带宽低的发布/子协议，非常适合处理能力有限的网络和设备。MQTT 还能处理断断续续的网络连接，并支持服务质量（QoS）级别，以确保可靠的信息传递。

对于复杂的交互或数据处理应用来说，MQTT 并不是最佳选择。但对于带宽和电池寿命要求较低的用例（MQTT 允许设备在信息之间 “休眠”，从而延长物联网设备的电池寿命），MQTT 能提供出色的功能。

事件驱动架构（EDA）

在 EDA 中，事件会触发系统内不同组件或服务之间的变化并进行通信。这样就可以进行实时和反应式数据处理，并减少对资源重复轮询的需求，而在基于 REST 的系统中，这种轮询可能会耗费大量资源和时间。

对于需要实时数据处理、可扩展性以及系统内不同组件或服务间松散耦合的应用程序来说，EDA 是一种很好的 REST 替代方案。它还非常适合微服务架构，允许每个微服务独立运行，并通过事件与其他服务通信。这使得整个系统具有更好的可扩展性、灵活性和弹性。

FALCOR

公司也可以在开发中推动创新。FALCOR 是 Netflix 开发的 JavaScript 库，用于构建高效灵活的 API。它采用 “基于路径 “的方法进行数据检索，将数据表示为相互连接的路径图，而不是通过 HTTP 请求访问的单个资源。它具有以下优点：

支持 WebSocket，可将实时数据更新推送到客户端，无需重复轮询

声明式数据获取：客户端指定所需的数据，应用程序接口响应所请求的数据。这简化了客户端代码，减少了通过网络发送的数据量。

FALCOR “这个名字并不代表什么。它是由 Netflix 的开发人员选择的，以代表该库的数据检索方法。它的灵感来源于 20 世纪 80 年代电影《永无止境的故事》中的同名角色，这是一种龙形生物，可以穿越不同的维度和世界，就像 FALCOR 浏览复杂数据图的能力一样。

Functions

PubNub 的 Functions 是 JavaScript 事件处理程序，可在途中的 PubNub 消息或 HTTPS 上的 RESTful API 的请求/响应样式中执行。对于熟悉 Node.js 和 Express 的人来说，On Request 事件处理程序的开发非常相似。功能可以部署新的或额外的实时功能，如聊天审核和语言翻译。

在 PubNub 的网络中运行您的代码，或利用现有的集成来转换、重新路由、增强、过滤和汇总消息，以检测和阻止垃圾邮件发送者、测量平均值等。所有代码都在边缘运行，延迟低，而且足够强大，您无需构建自己的基础设施。

一次促进一个 REST 替代方案的创新

REST 替代方案由于能够解决 REST API 面临的挑战而越来越受欢迎。每种替代方案都有自己独特的优势和用例。在选择 REST 替代方案时，必须考虑应用程序的特定需求和要求（无论是实时活动的规模还是 Web3 的实时功能），以及每种 REST 替代方案的优势和局限性。

最终，通过探索这些替代方案，开发人员可以构建更高效、更有效的 API，以满足现代应用的需求。