GraphQL vs REST：你需要知道的一切
已发表: 2022-09-20选择将包含在下一个项目的技术堆栈中的技术可能很困难。 在许多情况下——尤其是在 GraphQL 和 RESTful API 之间进行选择时——都是为了选择下一个最佳 API 设计架构。
构建 API 有四种重要的方法：SOAP、GRPC、REST 和 GraphQL。 每当我们想要构建 API 时，我们经常将注意力集中在 REST 和 GraphQL 上。 这是因为 REST 改变了使用 SOAP 和 GRPC 构建 API 的传统方式。
GraphQL 被广泛标记为更好的 REST，因为它代表了一种更好的构建 API 的方式。 许多开发人员认为 GraphQL 将取代 REST。 更多人已经发现 GraphQL 有助于解决开发人员在构建 REST API 时面临的一些常见挑战。
这两种构建 API 的方法完全不同。 在实践中，这些技术通过发送 HTTP 请求并接收结果来工作。 它们各有利弊，在本文中，我们将广泛讨论这两种改变了我们开发和扩展 API 方式的伟大技术。
不过，在深入了解细节之前，让我们先探讨一下 GraphQL 和 RESTful API 的含义。
什么是 GraphQL？
GraphQL 是一种 API 查询语言，也是使用现有数据回答这些查询的运行时。 它还配备了强大的工具来处理最复杂的查询。
GraphQL 的核心特性是它能够仅请求和接收所请求的特定数据——仅此而已。 这使得随着您的应用程序扩展您的 API 变得更加简单。
GraphQL 最令人兴奋的部分是它能够在一个端点中为您提供所有数据。
上图是 GraphQL 架构的典型表示。 客户端从不同的设备发出请求，GraphQL 处理他们的请求并只返回他们请求的数据。 这巧妙地解决了 RESTful API 中的过度获取和获取不足的问题。
在上面的示例中，我们展示了一个 GraphQL 游乐场以及如何使用单个端点查询数据。 顶部是 API 端点，左侧是请求大陆名称的查询，最后，在右侧，我们响应我们请求的查询。
GraphQL 由 Facebook 创建，主要目的是解决他们的移动应用程序开发人员在使用 REST API 时的体验。 自 2015 年发布第一个开源版本以来，GraphQL 经历了巨大的增长，因为科技行业的大公司采用了该技术。
使用 GraphQL 的公司
下面列出了一些在其服务器上积极使用 GraphQL 的公司和应用程序。
Facebook 创建了 GraphQL，自 2012 年以来，他们一直在生产中使用它来支持他们的移动应用程序。这家价值数十亿美元的社交网络公司于 2015 年开源了 GraphQL 规范，使其可以在许多环境和各种规模的团队中访问.
GitHub
GitHub 还通过提供 GraphQL API 来宣布使用 GraphQL，该 API 用于使用 GitHub GraphQL API 创建集成、检索数据和自动化您的工作流程。 GitHub GraphQL API 提供比 GitHub REST API 更精确和灵活的查询。
Pinterest 也是 GraphQL 的早期采用者。 这家照片共享巨头公开讨论了他们对 GraphQL 的早期探索，以及他们如何使用支持其价值数十亿美元的公司的 GraphQL 技术。
许多其他价值数十亿美元的公司，例如 Intuit、Shopify、Coursera 和 Airbnb，都使用 GraphQL 为他们的应用程序提供支持。 这种对 REST 的广泛偏好只会继续增长。
什么是 RESTful API？
REST 代表“Representational State Transfer”，这是一种分布式超媒体系统的软件架构风格。 它定义了服务器和客户端之间交换资源的原则和约束。
如果 API 遵循这些原则，则该 API 的应用程序称为“RESTful”。 WordPress REST API 就是一个很好的例子。
以下是 API 必须满足的一些原则和约束才能被称为 Restful API：
- 客户端-服务器解耦：客户端（前端）和服务器（后端）完全分离，只能通过端点进行通信。
- 统一的界面：界面中看到的数据在所有设备上都是相同的。
- 无状态：服务器不记得当前请求是否是第一次发出。 每次发出请求时，它都需要包含从头开始处理它所需的所有信息。
- 可缓存性：允许缓存和会话存储，但必须将它们配置为允许最终用户选择退出数据缓存。
- 分层系统架构： API 的设计必须使客户端和服务器都无法判断它们是直接通信还是通过中介进行通信。
下图是基本的 REST 架构。 它显示了通常如何处理请求和响应。
GraphQL 的好处
以下是使用 GraphQL 的一些好处，说明了为什么它对于构建下一个价值十亿美元的应用程序绰绰有余。
通过单个 API 端点获取数据
GraphQL 的最大优势在于它能够通过单个 API 端点访问任何或所有数据点。
RESTful API 最常见的问题之一是有太多端点来访问信息。 在 GraphQL 中，您只有一个端点，因此您无需发送多个请求来检索有关对象的不同信息。
下图描绘了一个使用 RESTful API 和 GraphQL 检索资源的清晰示例。 可以看到 GraphQL 服务器中只有一个端点可以访问资源，而 RESTful API 中需要多个 API 端点来访问不同的资源。
没有过度获取或不足获取
过度或不足的问题是 RESTful API 的一个已知问题。 这是当客户端通过点击返回固定数据结构的端点来下载数据时，或者他们检索的数据多于或少于他们的预期。
过度获取会导致请求接收（或“获取”）比给定请求所需的数据更多的数据。 想象一下，您正在获取一个表中的所有用户，目的是在您的主页上显示他们的用户名。 在这种情况下，过度获取将返回每个用户的所有数据，包括（但不仅是）名称。
想知道我们是如何将流量提高到 1000% 以上的吗？
加入 20,000 多人的行列，他们会通过 WordPress 内幕技巧获得我们的每周时事通讯！
获取不足的情况比较少见，但当特定端点未能提供所有请求的信息时，确实会发生这种情况。 客户将需要根据需要发出额外的请求以访问其他信息。
GraphQL 通过抓取客户端请求的确切资源而无需任何额外细节，有效地解决了过度获取或获取不足的问题。
更好地处理复杂系统和微服务
GraphQL 可以统一和隐藏集成多个系统的复杂性。
例如，假设我们想从单体后端应用程序迁移到微服务架构。 GraphQL API 通过将各种微服务合并到一个 GraphQL 模式中来帮助处理它们之间的通信。
一旦定义了这些模式，前端和后端就可以单独通信而无需任何进一步的更改，因为前端知道模式中的数据将始终在整个系统中保持同步。
快速安全
过度获取的问题可能会导致客户端的带宽消耗更高，这可能会及时导致您的应用程序滞后。 使用 RESTful API 设计模式从巨大的有效负载中整理出所需的信息更加耗时。
由于 GraphQL 能够避免过度获取和获取不足，服务器返回一个安全、易于阅读和可预测的形状，从而使您的 API 请求和响应更快。
REST 的好处
尽管 GraphQL 越来越受欢迎，但 REST 仍然是最流行的 API 标准之一。 让我们来看看为什么。
- 学习曲线： RESTful API 是最容易学习和理解的。 这是它优于其他 API 的主要优势。
- 序列化： REST 提供了一种灵活的方法和格式来序列化 JSON 中的数据。
- 缓存： REST API 可以在 HTTP 代理服务器和缓存的帮助下管理高负载。
- 复杂请求： REST API 对不同的请求有一个单独的端点，这有助于使复杂请求比其他 API 更易于管理
- 干净且简单： REST API 优雅、简单且干净。 它们很容易探索。
- 标准 HTTP 过程： REST 使用标准 HTTP 过程调用来检索数据并发出请求。
- 客户端/服务器：这意味着它的业务逻辑与表示分离。 所以你可以改变一个而不影响另一个。
- REST 是无状态的：客户端和服务器之间交换的所有消息都具有知道如何处理消息所需的所有上下文。
GraphQL 的缺点
既然我们已经讨论了 GraphQL 与 REST 的优点，让我们来探讨一下 GraphQL 的一些缺点：
- 困难的学习曲线： GraphQL 不像 REST 那样容易学习。 构建 GraphQL API 最具挑战性的部分是设计模式。 这需要大量时间和领域知识。
- 文件上传： GraphQL 没有原生文件上传功能。 这可以使用 Base64 编码来解决，但是以这种方式编码和解码的成本可能既耗时又昂贵。
- Web缓存：缓存有助于减少服务器的频繁流量，通过将频繁访问的信息保持在服务器附近，从而加快请求和响应过程。 GraphQL 不支持或不依赖 HTTP 缓存方法，而是依赖于 Apollo 或 Relay 客户端的缓存机制。
- 不适合小型应用程序： GraphQL 可能不是构建小型应用程序的最佳 API 架构。 如果您的应用不需要 GraphQL 提供的更灵活的查询，那么 REST 就是您的选择。
- 复杂查询问题： GraphQL 能够准确地为客户端提供所需内容的能力也可能导致查询传播问题。 如果客户端提交的嵌套查询过多，可能会导致发送错误的查询，这对服务器来说可能非常耗时。 最好使用带有自定义端点的 REST 来满足此类请求。
REST 的缺点
现在，让我们将注意力转向 REST 的一些缺点：
- 多次往返： REST API 的最大问题是众多端点的性质。 这意味着客户端要获取完整应用程序的所有资源，需要进行无数次往返才能获取数据。
- Over-fetching and Under-fetching：过度获取和不足获取的问题是 RESTful APIS 的一个主要缺点。 由于获取大量不需要的有效负载，它可能导致响应滞后。
- 层次结构：由于 REST API 是基于 URI 引用资源构建的，因此它们不适合在简单层次结构中自然组织或访问的资源。
为什么使用 GraphQL 而不是 REST
接下来，我们将讨论为什么您可能希望在未来的 API 开发中考虑使用 GraphQL 而不是 RESTful API。
强类型模式
GraphQL 使用强类型系统来定义 API 的功能。 在 GraphQL 中，模式定义语言 (SDL) 用于定义围绕客户端如何访问服务器数据的参数。 所有暴露给客户端的 API 都写在 SDL 中，解决了 RESTful API 中出现的数据不一致问题。
没有过度获取或获取不足
过度或不足的问题是 RESTful API 的一个已知问题，其中客户端返回的信息比他们请求的多或少。 GraphQL 通过为客户端提供一种媒介来指定所需信息，然后准确且仅返回该特定信息来解决此问题。
多个端点
RESTful API 的最大问题之一是有太多端点来访问信息。
假设您想通过他们的 ID 号访问特定用户。 您将看到像/users/1这样的端点。 但是，如果您想访问该用户的照片，则必须向另一个端点发送请求，例如/users/1/photos 。
在 GraphQL 中，您有一个端点，您无需发送多个请求来检索有关用户的不同信息。
GraphQL 与 REST 对决
最后，我们将探讨 GraphQL 和 RESTful API 之间的主要区别。 之后，我们将讨论一个好的 API 设计的一些特性，并比较每种技术如何处理它们。
表现
毫无疑问，GraphQL 比 RESTful API 执行得更快，因为它能够提供单个端点来访问您的所有资源。 RESTful API 使用多个端点，这可能会导致网络延迟。
查询复杂度
由于端点没有分成多个端点，GraphQL 查询会随着时间的推移变得越来越复杂。 另一方面，RESTful API 端点是分离的，这将 RESTful API 限制为简单的查询。
人气和社区支持
GraphQL 是一种不断发展的 API 架构模式和查询语言。 虽然它还很年轻，但它的采用率和资源池正在迅速增长，对于那些有兴趣自己学习它的人来说，资源已经比比皆是。
另一方面，REST 已经拥有广泛的社区支持，并继续被各种公司使用，从构建小型微服务的公司到创建复杂社交应用程序的公司等等。
目前，GraphQL 与 REST 的人气较量是平局。 这两种技术继续被开发社区广泛使用并得到很好的支持。
学习曲线
GraphQL 的学习曲线非常陡峭。 它需要 API 开发和通用软件工程的良好领域知识。 一个完整的初学者将很难充分理解 GraphQL 以构建复杂的应用程序。
相反，REST 非常容易上手，并且需要较少的领域知识。 RESTful API 很好地集成到大多数主要的编程语言和流行的框架中，这使得学习变得非常容易。
概括
GraphQL 是一种遵循 RESTful API 架构模式的新技术，就像引入 REST 来解决 SOAP API 模式的问题一样。
GraphQL 为您提供更快的响应、针对所有查询的单一 API 端点以及用于一致数据访问的严格模式。 这些原因使得价值数十亿美元的公司开始转向 GraphQL，即使是在早期阶段。 然而，尽管有其局限性，GraphQL 的祖先 REST 继续在舞台上保持强大的存在。
在本指南中，我们探讨了您需要了解的有关 GraphQL 和 RESTful API 的所有信息，包括每种技术的优缺点，以帮助您自信地决定您更喜欢哪一种。 我们还讨论了 RESTful API 的已知问题——例如过度获取、获取不足和多个端点——以及 GraphQL 如何尝试解决这些问题并提高应用程序的性能。
您现在已经有足够的洞察力来选择 GraphQL 与 REST 是否适合您的下一个项目。 在评论部分让我们知道您将与您选择的获胜者一起构建什么！