GraphQL 会取代 REST API 吗?
GraphQL 之所以越来越受欢迎,是因为它能够比 REST 更高效、更强大、更灵活地开发 API。
我们都知道 REST 是使用 API 的传统方法,但自 2015 年 GraphQL 发布以来,它真正受到了开发者的青睐。
GraphQL 是 API 的查询语言,它允许你随时获取所需的精确数据(不多不少)。它由 Facebook 开发,现在由一个大型开源社区维护。
GraphQL 的优势
让我们看一个例子:假设我们要开发一个博客应用,并希望显示特定用户的姓名、头衔和关注者。使用 REST API,我们可能需要将请求发送到多个端点才能满足数据需求。
例如:
/users/{id}/name
/users/{id}/posts/title
/users/{id}/followers
使用 REST API,你最终需要向服务器发送 3 个请求。而使用 GraphQL 时,我们只需向 GraphQL 服务器发送一个查询,服务器就会返回 JSON 数据。
query {
User {
name
posts {
title
comments {
comment
}
}
followers {
name
}
}
}
我们将收到如下响应:
{
"data":
{
"user": {
"name": "John Doe",
"posts": [
{
"title": "How to fetch data from an API",
"comments": [
{
"comment": "Great post."
}
]
},
{
"title": "How to build REST API with Node.js",
"comments": [
{
"comment": "So neat & precisely written."
}
]
}
]
"followers": [
{
"name": "Ben Smith"
}
]
}
}
}
不会出现过度获取或获取不足的情况
过度获取意味着客户端下载的数据超过所需,而获取不足意味着特定端点没有提供客户端所需的足够数据。
在 REST API 中,每个端点都有一个固定的数据结构,这意味着大多数时候我们获取的数据比我们实际需要的要多,或者我们需要调用多个端点来满足我们的数据需求。
就 GraphQL 而言,它允许客户端通过单个请求从多个资源请求数据,从而解决了过度获取和获取不足的问题。
加快开发进程
假设你正在开发一个项目,其产品需求突然发生变化,最糟糕的情况发生了:REST API 需要一个新的端点。在这种情况下,前端开发团队的工作将受阻,并且将完全依赖于后端开发团队。
GraphQL 使前端开发人员的生活变得更轻松,因为客户端上使用的数据不再与端点的资源耦合,从而加快了前端和后端开发团队的开发过程。
GraphQL 与 REST 的比较
受欢迎程度
GraphQL 在过去几年中呈指数级增长。
根据《2021 年 API 集成现状报告》,
75% 的受访者预计 GraphQL 将成为未来 API 的主导查询语言。相比之下,2020 年只有 40% 的受访者表示 GraphQL 将成为未来的主流方法。
但 REST 仍然是 2021 年 API 报告受访者中最受欢迎的,因为他们认为 GraphQL 落后于行业采用。
可用性
使用 GraphQL 查询从数据库中获取所需的精确数据非常简单。由于可以获得可预测的结果,这使得数据使用变得更加容易。
与 REST 相比,GraphQL 返回特定端点的所有可用数据。这可能会导致数据转储,客户端必须下载不必要的、未使用的数据。
可以说,与 REST 相比,GraphQL 更易于使用。
表现
GraphQL 中的自定义查询可以通过多种方式提高效率,从减少 API 请求数量到确保返回适当的数据量。
不过……REST API 的性能可能更胜一筹。为了
更快地返回缓存结果,REST API 使用内置的 HTTP 缓存机制,该机制在需要缓存来快速处理 API 调用的情况下性能更佳。GraphQL 也支持缓存,但缓存程度不如 REST。
优点和缺点
GraphQL 的优点:
提供一致、统一的数据。
消除过度获取和获取不足的问题。
加快开发流程。
GraphQL 的缺点
:缺乏内置缓存。
错误处理复杂。
缺乏行业采用和支持。
REST API 优点
支持不同的数据格式(Html、JSON 等)
流行且得到社区的广泛采用和支持。
REST API 的缺点是
需要多次向服务器发送请求才能获取所有所需数据。
缺乏构建 API 的具体方法。
结论
我不是 API 专家,但我发现使用 GraphQL 真的非常有趣和令人着迷。如果你正在寻找哪种 API 更好,那你可能来错地方了。哪种 API 形式更好,实际上取决于每个应用程序的用例。
我建议尝试一下这两个方法,看看是否适合您的开发工作流程。
如果你有什么想分享的观点,请在下方评论。
希望你喜欢这篇文章。
继续学习!