API格局在不断发展，一些协议越来越受欢迎，而另一些则逐渐衰落。Postman 最新的 API 现状报告(https://www.postman.com/state-of-api/api-global-growth/) 基于对 40,000 多名开发人员的调查，提供了这些转变的快照，并揭示了哪些 API 协议目前最受关注和采用。在本文中，我们将详细探讨这些 API 协议，分析它们为何引起如此大的兴趣，并深入探讨每个协议的主要优势和局限性。
Restful
代表态转移（REST）仍然是Web API最受欢迎的建筑风格。尽管其在调查受访者中的使用率略有下降——在过去两年中从92%降至86%——但其简单性、可扩展性和与Web服务的易集成性巩固了其在顶部的地位。 具象状态传输 （REST） 仍然是 Web API 最流行的架构风格。尽管它在受访者中的使用率略有下降（在过去两年中从 92% 下降到 86%），但它的简单性、可扩展性以及与 Web 服务的易集成巩固了它的领先地位。
REST的好处REST 的优势
- 简单和标准化：通过利用标准HTTP方法，REST能够为已经精通HTTP的开发人员提供直接采用。这种简单性促进了快速学习和整合。 简单性和标准化：通过利用标准的HTTP方法，REST使已经精通HTTP的开发人员能够直接采用。这种简单性促进了快速学习和集成。
- 可扩展性：REST的无状态性质确保服务器不需要在请求之间存储会话数据。这通过添加没有共享服务器状态的实例来促进水平扩展。 可扩展性：REST的无状态特性确保服务器不需要在请求之间存储会话数据。这通过添加没有共享服务器状态的实例来促进水平扩展。
- 性能：无状态和可缓存响应产生更快的执行和更少的请求。 性能：无状态和可缓存响应可加快执行速度并减少请求数。
- 模块化：RESTful服务可以作为模块化组件开发。这种本地化功能可以实现独立更新并提高可维护性。 模块化：RESTful服务可以作为模块化组件进行开发。这种本地化功能可实现独立更新并提高可维护性。
- 平台无关：平台无关的HTTP支持允许不同客户使用。由此产生的互操作性促进了跨系统的API集成。 与平台无关：与平台无关的 HTTP 支持允许不同的客户端使用。由此产生的互操作性促进了跨系统的 API 集成。
- 成熟的工具和社区支持：REST的长寿导致了工具、库、最佳实践、故障排除指导和社区资源的广泛扩散。 成熟的工具和社区支持：REST 的长期存在导致了工具、库、最佳实践、故障排除指南和社区资源的广泛扩散。
REST的挑战REST的挑战
- 过度获取和不足：REST存在过度获取或不足数据的风险，因为客户端可能只需要一部分资源。这种缺点可能会导致性能问题和浪费带宽。 过度获取和获取不足：REST 存在过度获取或未获取数据的风险，因为客户端可能只需要一部分资源。此缺点可能会导致性能问题并浪费带宽。
- 聊天界面：检索相关数据可能需要多个请求，这会增加延迟。随着应用程序的扩展，这种呼叫瀑布变得特别有问题。 聊天界面：检索相关数据可能需要多个请求，这会增加延迟。随着应用程序规模的扩展，这种调用瀑布式变得尤其成问题。
- 版本挑战：创建新版本的REST API可能很麻烦，特别是当数据结构或服务功能发生变化时。这通常会导致向后兼容性问题。 版本控制挑战：创建 REST API 的新版本可能很麻烦，尤其是在数据结构或服务功能发生更改时。这通常会导致向后兼容性问题。
- 无状态开销：虽然无状态支持可扩展性，但也意味着每个请求都必须提供所有必要的上下文。这一要求可能会带来开销，特别是当客户必须发送大量重复数据时。 无状态开销：虽然无状态支持可伸缩性，但这也意味着必须为每个请求提供所有必要的上下文。此要求可能会带来开销，尤其是当客户端必须发送大量重复数据时。
- 缺乏实时功能：REST没有针对聊天或实时提要等实时应用程序进行优化。WebSockets和服务器发送的事件通常更适合此类用例。 缺乏实时功能：REST 未针对实时应用（如聊天或实时提要）进行优化。WebSocket 和服务器发送的事件通常更适合此类用例。
WebhooksWebhook
Webhook是由源应用程序中的事件触发的用户定义的HTTP回调。当事件发生时，源应用程序向目标应用程序指定的URI发送HTTP请求（通常是POST），这可以在不重复轮询的情况下实现近实时的基于事件的通信。Webhook越来越受欢迎，36%的开发人员使用它们在不同系统之间创建无缝集成。 Webhook 是用户定义的 HTTP 回调，由源应用程序中的事件触发。当事件发生时，源应用程序会向目标应用程序指定的 URI 发送 HTTP 请求（通常为 POST），从而实现近乎实时的基于事件的通信，而无需重复轮询。Webhook 正变得越来越流行，36% 的开发人员使用它们在不同系统之间创建无缝集成。
例如，如果您想在博客文章上有新评论时收到通知，而不是反复询问（投票）服务器“有新评论吗？”，服务器会在发布新评论时（通过网络钩子）通知您。 例如，如果你想在每次博客文章上有新评论时都收到通知，而不是反复询问（轮询）服务器，“有没有新评论？”，服务器会在发布新评论时通知你（通过 webhook）。
网络钩子的好处Webhook 的优势
- 实时通信：Webhook可实现实时数据传输。事件触发时会发送相应的数据，确保系统之间的最新同步。 实时通信：Webhook 支持实时数据传输。当事件被触发时，会发送相应的数据，确保系统之间的最新同步。
- 效率：Webhook消除了资源密集型轮询，节省了计算能力和带宽。 效率：Webhook 消除了资源密集型轮询，节省了算力和带宽。
- 灵活性：Webhooks可以配置为响应特定事件，允许您自定义一个应用程序中的哪些操作或触发器将向另一个应用程序发送数据。 灵活性：Webhook 可以配置为响应特定事件，允许您自定义一个应用程序中的哪些操作或触发器将数据发送到另一个应用程序。
- 简化集成：HTTP方法使大多数应用程序易于使用。 简化的集成：HTTP 方法使大多数应用程序能够轻松使用。
- 支持解耦架构：由于网络钩子基于事件运行，它们自然支持事件驱动或解耦架构，增强了模块化和可扩展性。 支持解耦架构：由于 Webhook 基于事件运行，因此它们自然支持事件驱动或解耦架构，从而增强了模块化和可扩展性。
网络钩子的挑战Webhook 的挑战
- 错误处理：如果网络钩子接收端停机或处理回调时出现错误，则存在数据丢失的风险。使用网络钩子的系统必须具有强大的错误处理机制，包括重试或日志。 错误处理：如果 Webhook 的接收端关闭或在处理回调时出现错误，则存在数据丢失的风险。使用 Webhook 的系统必须具有可靠的错误处理机制，包括重试或日志。
- 安全问题：网络钩子通过互联网传输数据，使它们容易受到拦截或恶意攻击。API安全措施，如使用HTTPS和有效负载签名，是必不可少的。 安全问题：Webhook 通过 Internet 传输数据，使其容易受到拦截或恶意攻击。API 安全措施（例如使用 HTTPS 和有效负载签名）至关重要。
- 管理多个网络钩子：管理和监控网络钩子可能很复杂，特别是随着应用程序的发展并开始依赖多个网络钩子。确保所有网络钩子正常运行并跟踪各种端点需要勤奋。 管理多个 Webhook：管理和监视 Webhook 可能很复杂，尤其是当应用程序增长并开始依赖多个 Webhook 时。确保所有 Webhook 正常运行并跟踪各种端点需要勤奋。
- 潜在的过载：大量并发回调可能会使接收应用程序不堪重负，但速率限制或批处理可能有助于管理激增。 潜在的过载：大量并发回调可能会使接收应用程序不堪重负，但速率限制或批处理可能有助于管理激增。
GraphQL
GraphQL是一种API的查询语言，也是使用您为数据定义的类型系统执行查询的服务器端运行时。GraphQL由Facebook于2012年开发，并于2015年作为开源项目发布，为传统的REST API提供了一个更灵活、更高效的替代品。GraphQL在开发人员中的采用率增长了29%，这表明其在当今API环境中的重要性。 GraphQL 是一种用于 API 的查询语言，也是一种服务器端运行时，用于使用您为数据定义的类型系统执行查询。GraphQL 由 Facebook 于 2012 年开发，并于 2015 年作为开源项目发布，为传统的 REST API 提供了更灵活、更高效的替代方案。GraphQL 在开发人员中的采用率高达 29%，这表明它在当今 API 环境中的重要性。
与REST不同，您必须点击多个API端点才能获取相关数据，GraphQL允许您在单个查询中获得所需的所有数据。这对前端开发人员特别有用，因为它使他们能够更好地控制数据检索过程，并允许他们创建更动态和响应灵敏的用户界面。 与 REST 不同，在 REST 中，您必须点击多个 API 端点才能获取相关数据，而 GraphQL 允许您在单个查询中获取所需的所有数据。这对前端开发人员特别有用，因为它使他们能够更好地控制数据检索过程，并允许他们创建更动态和响应更灵敏的用户界面。
GraphQL的好处GraphQL 的优势
- 强类型模式：GraphQL API具有强类型模式，允许开发人员确切知道哪些数据和类型可供查询。 强类型架构：GraphQL API 具有强类型架构，使开发人员能够确切地知道哪些数据和类型可供查询。
- 精确的数据检索：客户可以请求他们需要的精确数据，这解决了过度获取和获取不足的问题，进而提高性能并降低成本。 精准数据检索：客户可以请求所需的精准数据，解决了超取和欠取的问题，进而提高了性能，降低了成本。
- 查询复杂性和多个资源：GraphQL支持在一个请求中查询多种数据类型，这减少了复杂、相互关联的数据的网络请求数量。 查询复杂度和多种资源：GraphQL 支持在一次请求中查询多种数据类型，从而减少了对复杂、相互关联的数据的网络请求数量。
- 订阅实时更新：GraphQL通过订阅实现实时同步，使客户端实时更新。 订阅实时更新：GraphQL 支持通过订阅进行实时同步，从而使客户端实时更新。
- 内省：GraphQL的自我记录模式使通过内省更容易开发。 内省：GraphQL 的自文档模式通过内省实现更轻松的开发。
GraphQL的挑战GraphQL 的挑战
- 查询复杂性：GraphQL赋予客户端的灵活性有缺点，因为过度复杂或嵌套的查询可能会对性能产生负面影响。 查询复杂性：GraphQL 为客户端提供的灵活性也有缺点，因为过于复杂或嵌套的查询会对性能产生负面影响。
- 学习曲线：由于突变和订阅等新概念，GraphQL的学习曲线比REST更陡峭。 学习曲线：由于突变和订阅等新概念，GraphQL 的学习曲线比 REST 更陡峭。
- 版本控制：查询的灵活性意味着模式的变化可能会破坏现有查询，使版本管理复杂化。 版本控制：查询的灵活性意味着架构中的更改可能会破坏现有查询，从而使版本管理复杂化。
- 资源的潜在过度使用：由于客户可以在一个查询中请求多个资源，因此通过获取不必要的数据，存在服务器超载的风险。 潜在的资源过度使用：由于客户端可以在一个查询中请求多个资源，因此存在通过获取不必要的数据而使服务器过载的风险。
- 安全问题：恶意用户可以利用GraphQL的灵活性，用复杂的查询使服务器超载。 安全问题：恶意用户可能会利用 GraphQL 的灵活性，通过复杂的查询使服务器过载。
什么是 GraphQL？它是 REST API 的替代品吗？
下图显示了 REST 和 GraphQL 之间的快速比较。
GraphQL 是 Meta 开发的一种 API 查询语言。它提供了 API 中数据的完整描述，并让客户端能够准确请求他们所需的内容。
GraphQL 服务器位于客户端和后端服务之间。
GraphQL 可以将多个 REST 请求聚合为一个查询。GraphQL 服务器以图形形式组织资源。
GraphQL 支持查询、变异（将数据修改应用于资源）和订阅（接收有关架构修改的通知）。
我们在上周的视频中讨论了 REST API，并将在单独的帖子/视频中比较 REST、GraphQL 和 gRPC。
交给你：
1). GraphQL 是一种数据库技术吗？
2). 你推荐 GraphQL 吗？为什么/为什么不推荐？
SOAP
简单对象访问协议（SOAP）是一种用于交换结构化信息以实现Web服务的协议。它使用XML作为消息格式，通常使用HTTP或SMTP作为消息协商和传输层。与REST和GraphQL不同，SOAP具有严格的标准和内置功能，如符合ACID的交易、安全性和消息模式。 简单对象访问协议 （SOAP） 是一种用于交换结构化信息以实现 Web 服务的协议。它使用 XML 作为其消息格式，通常使用 HTTP 或 SMTP 作为消息协商和传输层。与 REST 和 GraphQL 不同，SOAP 具有严格的标准和内置功能，如符合 ACID 的事务、安全性和消息传递模式。
尽管其使用量减少——仅占开发人员的26%——但SOAP是某些应用程序的可靠选择。让我们探索是什么让SOAP与众不同，以及与其他API设计方法相比，它闪耀的地方。 尽管SOAP的使用率有所降低（仅占开发人员的26%），但对于某些应用程序来说，SOAP仍是可靠的选择。让我们来探讨一下 SOAP 的独特之处，以及它与其他 API 设计方法相比的优势。
SOAP的好处SOAP 的优点
- 强大的类型和合同：SOAP API具有强大的类型和严格的合同，该合同在Web服务描述语言（WDSL）文档中定义。 强类型化和协定：SOAP API 具有强类型化和在 Web 服务描述语言 （WDSL） 文档中定义的严格协定。
- 内置安全功能：SOAP通过WS-Security标准提供全面的身份验证、授权和加密。这使得SOAP成为企业应用程序的首选。 内置安全功能：SOAP 通过 WS-Security 标准内置的身份验证、授权和加密功能提供全面的安全性。这使得 SOAP 成为企业应用程序的首选。
- ACID交易：SOAP支持ACID交易，这对数据完整性至关重要的应用程序（如金融或医疗保健系统）至关重要。 ACID 事务：SOAP 支持 ACID 事务，这对于数据完整性至关重要的应用程序（如金融或医疗保健系统）至关重要。
- 可靠的消息传递：SOAP确保可靠的消息传递并很好地处理故障，这使得它非常适合保证消息传递至关重要的系统。 可靠的消息传递：SOAP 可确保可靠的消息传递并很好地处理故障，这使得它非常适合有保证的消息传递至关重要的系统。
- 语言、平台和传输中立性：与REST类似，任何了解XML的客户端都可以使用SOAP服务，无论其底层编程语言、平台或传输协议如何。 语言、平台和传输中立性：与 REST 类似，任何理解 XML 的客户端都可以使用 SOAP 服务，而不管其基础编程语言、平台或传输协议如何。
SOAP的挑战SOAP的挑战
- 复杂性和学习曲线：由于其严格的标准和使用XML，SOAP的实施可能更加复杂，使学习曲线比REST或GraphQL等替代方案更陡峭。 复杂性和学习曲线：由于SOAP的严格标准和XML的使用，SOAP的实现可能更加复杂，这使得学习曲线比REST或GraphQL等替代品更陡峭。
- 更 Verbose消息：SOAP消息头承担大量开销，导致比REST和GraphQL的JSON更大的有效负载。这会影响性能和带宽使用。 冗长的消息：SOAP 消息标头会带来大量开销，这导致负载比 REST 和 GraphQL 的 JSON 更大。这可能会影响性能和带宽使用率。
- 有限的社区支持：SOAP正在失去优势，这意味着社区支持和可用的图书馆正在减少。 有限的社区支持：SOAP 正在失去优势，这意味着社区支持和可用库正在下降。
- 灵活性较小：合同的任何更改都可能需要客户端和服务器更新各自的实现，这可能是一个缺点。 灵活性较低：合约中的任何更改都可能需要客户端和服务器更新各自的实现，这可能是一个缺点。
- 防火墙问题：SOAP可能会使用与HTTP/HTTPS不同的传输协议，这意味着它可能会面临防火墙限制。这使得SOAP对某些部署环境来说不那么通用。 防火墙问题：SOAP 可能使用与 HTTP/HTTPS 不同的传输协议，这意味着它可能面临防火墙限制。这使得 SOAP 对于某些部署环境的通用性降低。
WebSocketWebSocket的
WebSocket在客户端和服务器之间提供持久、低延迟、双向连接，实现实时数据传输。与HTTP的请求响应周期不同，WebSocket允许服务器在初始握手后随时向客户端发送数据。这有助于聊天应用程序、在线游戏、交易平台等的即时数据更新。 WebSocket 在客户端和服务器之间提供持久、低延迟的双向连接，从而实现实时数据传输。与 HTTP 的请求-响应周期不同，WebSocket 允许服务器在初始握手后的任何时间向客户端发送数据。这有助于聊天应用程序、在线游戏、交易平台等的即时数据更新。
调查结果显示，25%的开发人员使用WebSocket。让我们探索它的优势、挑战和用例。 调查结果显示，25% 的开发人员使用 WebSocket。让我们探讨一下它的优势、挑战和用例。
WebSocket的好处WebSocket 的优势
- 实时双向通信：实时双向通信的延迟比每个交换必须重新建立的HTTP连接要少。 实时双向通信：实时双向通信的延迟比必须为每个交换重新建立的 HTTP 连接要少。
- 较低的开销：连接在初始握手后保持开放，这降低了传统HTTP请求附带的标头的开销。 降低开销：连接在初始握手后保持打开状态，从而降低了传统 HTTP 请求附带的标头开销。
- 高效利用资源：持久连接比长时间轮询更有效地使用服务器资源。 有效利用资源：持久连接比长轮询更有效地使用服务器资源。
WebSocket的挑战WebSocket 的挑战
- 实现复杂性实施WebSocket可能比其他API架构更复杂、更耗时——特别是当您考虑到在不支持WebSocket的环境中需要回退时。 实现复杂性实现 WebSocket 可能比其他 API 架构更复杂、更耗时，尤其是当您考虑到在不支持 WebSocket 的环境中需要回退时。
- 缺乏内置功能与内置安全和交易功能的SOAP不同，WebSocket更简单。它要求开发人员自己实现这些功能。 缺乏内置功能与带有内置安全和事务功能的 SOAP 不同，WebSocket 更简单。它要求开发人员自己实现这些功能。
- 资源消耗尽管开放的WebSocket连接通常比长期轮询技术更高效，但它们仍然会消耗服务器资源，并可能成为大规模关注的问题。 资源消耗尽管开放式 WebSocket 连接通常比长轮询技术更有效，但它们仍然会消耗服务器资源，并且可能会成为大规模问题。
- 网络限制一些代理和防火墙不支持WebSocket，导致某些网络环境中的潜在连接问题。 网络限制某些代理和防火墙不支持 WebSocket，从而导致某些网络环境中的潜在连接问题。
gRPCgRPC的
gRPC代表“谷歌远程程序呼叫”，是一种现代、高性能的协议，可促进服务之间的通信。它建立在HTTP/2之上，并利用协议缓冲区来定义服务方法和消息格式。与依赖GET和POST等标准HTTP动词的REST API不同，gRPC使服务能够公开类似于编程语言中函数的自定义方法。 gRPC 代表“Google 远程过程调用”，是一种现代的高性能协议，可促进服务之间的通信。它建立在 HTTP/2 之上，并利用协议缓冲区来定义服务方法和消息格式。与依赖于标准 HTTP 谓词（如 GET 和 POST）的 REST API 相比，gRPC 使服务能够公开类似于编程语言中的函数的自定义方法。
gRPC的好处gRPC 的优点
- 性能：HTTP/2和协议缓冲区使gRPC能够实现低延迟和高吞吐量。 性能：HTTP/2 和协议缓冲区使 gRPC 能够实现低延迟和高吞吐量。
- 强打字：像SOAP和GraphQL一样，gRPC是强打字的。随着类型在编译时被验证，这导致错误减少。 强类型：与 SOAP 和 GraphQL 一样，gRPC 是强类型。这样可以减少错误，因为在编译时会验证类型。
- 多语言支持：gRPC对许多编程语言有一流的支持，包括Go、Java、C#和Node.js。 多语言支持：gRPC 对许多编程语言提供一流的支持，包括 Go、Java、C# 和 Node.js。
- 流媒体：gRPC开箱即用地处理流媒体请求和响应，解锁了长期连接和实时更新等复杂用例。 流式处理：gRPC 开箱即用地处理流式处理请求和响应，从而解锁复杂的用例，例如长期连接和实时更新。
- 包括电池：gRPC直接支持负载平衡、重试和超时等关键功能。 包括电池：gRPC 直接支持负载均衡、重试和超时等关键功能。
gRPC的挑战gRPC 的挑战
- 浏览器支持：浏览器中的原生gRPC支持仍然有限，使其不太适合Web应用程序中的直接客户端到服务器通信。 浏览器支持：浏览器中的本机 gRPC 支持仍然有限，因此不太适合 Web 应用程序中的直接客户端到服务器通信。
- 学习曲线：开发人员需要学习如何使用协议缓冲区、自定义服务定义和其他gRPC功能，这可能会降低初始生产力。 学习曲线：开发人员需要学习如何使用协议缓冲区、自定义服务定义和其他 gRPC 功能，这可能会降低初始工作效率。
- 调试复杂性：协议缓冲区不可人类阅读，这使得调试和测试gRPC API比JSON API更难。 调试复杂性：协议缓冲区不是人类可读的，因此调试和测试 gRPC API 比 JSON API 更难。
其他API协议其他 API 协议
虽然之前讨论的协议是当今API领域最广泛采用的，但Postman的API状态报告还强调了一些服务于特定用例的其他方法： 虽然前面讨论的协议是当今 API 领域中采用最广泛的协议，但 Postman 的 API 现状报告还强调了其他一些服务于特定用例的方法：
- MQTT是一种针对物联网等低带宽网络优化的轻量级消息传递协议。它允许客户通过经纪人发布和订阅消息，但它缺乏一些安全性和可扩展性功能。 MQTT 是一种轻量级消息传递协议，针对物联网等低带宽网络进行了优化。它允许客户端通过代理发布和订阅消息，但它缺乏一些安全性和可伸缩性功能。
- AMQP是一个更强大的企业消息传递标准，可确保可靠的传递和灵活的消息路由。然而，它可能很复杂，并且比轻量级协议有更多的开销。 AMQP 是一种更强大的企业消息传递标准，可确保可靠的消息传递和灵活的路由。但是，它可能很复杂，并且比轻量级协议具有更多的开销。
- SSE通过HTTP实现单向服务器到客户端通信。它非常适合实时更新，但它缺乏双向功能。 SSE 支持通过 HTTP 进行单向服务器到客户端的通信。它非常适合实时更新，但缺乏双向功能。
- EDI通过标准化采购订单和发票等电子文档来自动化B2B通信，但它也需要具有高初始成本的复杂基础设施。 EDI 通过标准化采购订单和发票等电子文档来自动化 B2B 通信，但它也需要复杂的基础设施和高昂的初始成本。
- EDA推广了组件响应事件的事件驱动架构，使可扩展但调试复杂的实时系统成为可能。 EDA 提倡事件驱动架构，其中组件对事件做出反应，使实时系统具有可扩展性，但调试复杂。
这些协议并不普遍，但它们支持物联网、企业消息传递、B2B交易和事件驱动系统的专业应用程序。通过选择适合其特定需求的正确方法，开发人员可以构建超越通用标准的优化API解决方案。 这些协议并不普遍，但它们支持物联网、企业消息传递、B2B 交易和事件驱动系统中的专业应用。通过根据其特定需求选择正确的方法，开发人员可以构建超越通用标准的优化 API 解决方案。
结论
随着开发人员采用新的架构、协议和工具，API格局继续发展。虽然REST因其简单性和无处不在而仍然占主导地位，但GraphQL和gRPC等替代品正在通过解决过度调和聊天界面等痛点而获得牵引力。开发人员也越来越重视实时通信，随着网络钩子和WebSocket的崛起来满足这一需求。 随着开发人员采用新的架构、协议和工具，API 环境也在不断发展。虽然 REST 因其简单性和无处不在而仍然占据主导地位，但像 GraphQL 和 gRPC 这样的替代品通过解决过度获取和聊天界面等痛点而越来越受欢迎。开发人员也越来越重视实时通信，Webhook 和 WebSocket 的兴起满足了这一需求。
对于许多常见的API用例来说，鉴于其可扩展性、互操作性和易用性，REST仍然是一个坚实的基础方法。它还受益于社区成熟。尽管如此，每个协议都会带来权衡，随着应用程序变得越来越复杂，开发人员正在明智地扩展他们的API协议工具包，以包括GraphQL和gRPC等专业解决方案。 对于许多常见的 API 用例，鉴于其可扩展性、互操作性和易采用性，REST 仍然是一种坚实的基础方法。它仍然受益于社区的成熟度。尽管如此，每个协议都存在权衡取舍，随着应用程序变得越来越复杂，开发人员正在明智地扩展他们的 API 协议工具包，以包括 GraphQL 和 gRPC 等专门的解决方案。
与其说是某个协议是万能的灵丹妙药，不如让现代 API 开发人员了解多种协议的优缺点。通过构建结合 REST、Webhook、WebSockets、GraphQL 和其他独特方法的系统，开发人员可以构建健壮、高效且可维护的 API。虽然单个协议的受欢迎程度将继续波动，但总体趋势是 API 领域的多样性增加。开发人员应该接受这种多协议理念来制定最佳的 API 解决方案。
