在过去的几年中，我们一直听说GraphQL（一种允许客户端请求特定数据的 API 查询语言）是 API 的未来。

它的“炒作”来自Facebook或称Meta 明确且令人信服的价值主张。

也就是说，它可以帮助你获取所需的精确数据，并通过单个请求即可访问多个资源，从而节省开发者的时间、金钱和带宽。

但是当你开始使用 GraphQL时，就会发现它会产生一系列全新的问题，可能会抵消其带来的好处。

我将分析这些问题，以便帮助你更好地决定 GraphQL 是否值得在应用程序中使用。我还将重点介绍为什么 REST 是当今更好的替代方案，并将继续成为领先的 API 标准。

GraphQL 的缺点

我们来指出使用 GraphQL 的几个基本问题。

首先，GraphQL 通常会导致复杂的查询，会严重影响后端性能。这可能会导致较长的处理时间，从而抵消 GraphQL 承诺的优势之一 — 更快的响应时间。深度嵌套的查询甚至可能导致服务器宕机，从而进一步延迟响应。

此外，GraphQL 通常根据请求的复杂性（例如请求的字段或对象的数量）应用速率限制。随着您随着时间的推移增加请求中的资源，理解和遵循速率限制将变得更加复杂。

最后，随着 API 的成熟，其 GraphQL 模式会变得更加复杂。成功驾驭这种日益复杂的情况，不仅从速率限制的角度来看很痛苦，而且还可能在您的团队构建请求时导致代价高昂的错误。

为什么 REST 更好，并且会继续存在？

以下是 REST 成为集成 SaaS 应用程序的最佳选择的几个原因。

1. REST API 带有标准化的错误代码

这些代码包括从 404（资源未找到）到 500（内部服务器错误）的所有内容，可让你轻松诊断问题，并构建可自动解决问题的错误处理流程。例如，如果您收到 429 请求过多错误，您可以根据响应中建议的等待时间或创建自动重试。

另一方面，GraphQL 要求研发工程师考虑错误键中提供的响应。由于这些响应不像 REST 中那样标准化，因此比较难规划和自动处理。

2. 许多研发工程师都有构建和/或维护 REST API 集成的经验

各种规模的公司都主要使用 REST API。

我们根据 Gartner 的研究数据表明，85% 的组织使用 REST API，而有 19% 的组织开始使用 GraphQL。

鉴于 REST 的流行，你的开发团队可能经验丰富，并且能够熟练构建和维护 REST API 集成。此外，寻找和聘用具有 REST 工作经验的工程人才也更省力，从而使您的组织能够更轻松地随时间扩展 REST API 集成。

此外，虽然 API 提供商不可避免地会难以让开发人员与他们整合，但以开发人员最熟悉的架构提供 API 将消除采用方面的重大障碍。

3. REST 的开源生态系统比 GraphQL 的更加全面

目前，各种 REST 后端框架和库都可以自动生成 OpenAPI 规范。

这些工具还支持各种类型的编程语言，让开发工程师能够使用自己最熟悉的语言进行工作。

除了 OpenAPI，你还可以访问各种开源工具来管理 REST API 开发的各个方面，包括验证、安全、监控和测试等。

Postman 非常适合测试 REST API；OpenAPI 允许你自动生成 API 文档；REST 框架（例如，Django REST Framework）是为特定的编程语言构建的，并提供可帮助人们高效构建 API 的工具等。

这并不是说不存在适用于 GraphQL 的工具；只是有更多与 REST 相关的扩展得到了更好的支持。

结语

随着 API 领域不断成熟，我猜测将会新发明更多的 API 架构，并可能与 GraphQL 一样的“炒作”行为。

因此，除非竞争 API 架构能够超越（不用说匹敌） REST 对提供商和消费者的实用性，否则 REST 仍将是人们的首选。

各位觉得呢？欢迎点赞、分享、留言！～

作者：聆听世界的鱼