GraphQL Vs. REST? API 开发方法的诚实比较 | transposit


对 GraphQL 和 REST API 开发方法及其用例之间差异的动手探索:
无论您是在开发内部工具、内容管理系统 (CMS) 集成还是电子商务插件,您都会经常发现自己在做出选择。您应该使用标准的 REST API 还是 GraphQL API?
Facebook 于 2012 年制定了 GraphQL 规范。自 2015 年公开发布以来,GraphQL 已被构建 API 的公司广泛采用。尽管 GraphQL 基于并包含 REST 熟悉的许多功能,但两个系统处理数据的方式存在根本差异。
你需要决定吗?在为客户端开发 API 时,您可能想知道是否应该并行开发两种端点。本文探讨了这两种 API 开发方法,为您提供有关如何处理下一个项目的明智决定所需的所有知识。
 
好消息是这两种方法都使用相同的技术。
作为开发人员,您通过 HTTP 发送请求并期待响应。您使端点可用并在 API 级别为您的用户保护它们。您构建服务器,您的客户使用他们的代码查询它们。因此,您需要编写高效的代码来尽快满足客户的数据需求。
这些 API 方法之间的区别在于它们向服务器发送什么数据以及到达时会发生什么。
  
获取数据区别
两个 API 之间的第一个关键区别是 GraphQL API 通常有一个端点,单个 HTTP 动词查询。但是,RESTful API 有许多端点,多个动词可以查询这些端点。
让我们想象一下使用 RESTful 方法为 CMS 构建 API。这个基本的 CMS 有“用户”写的“帖子”,可能还有其他“用户”创建的“评论”。编写此 API 时,您需要创建多个端点:

  • GET /api/posts - 此端点允许客户端访问所有帖子。
  • POST /api/posts/:id - 此端点允许客户端创建帖子。
  • PATCH /api/posts/:id - 此端点允许客户端更新帖子。
  • DELETE /api/posts/:id- 此端点允许客户端删除帖子。

您还需要为其他每个资源、“用户”和“评论”创建此结构。
此 API 的典型用例是客户端尝试检索包含作者详细信息以及任何相关评论的帖子。您有两种可能的选择来支持此用户。您可以创建自定义端点/api/post-with-details或记录客户端需要发出的三个请求。
让我们想象一下使用 GraphQL 方法完成相同的练习。数据模型和后端存储仍然相同,但您将只公开一个端点,例如https://api.ourproduct.com/graphql. 您的客户端将向此端点发布 GraphQL 查询。然后,您将解析并响应查询。请求可能如下所示:
query {
 posts {
   title
   content
   date
   author {
     name
     byline
   }
   comments {
     content
     date
     author {
       name
     }
   }
}

您可以在这里确切地看到您的客户的要求。如果他们想要更多或更少的细节,他们可以简单地编辑他们的查询。他们控制自己想要什么。随着他们的数据需求发生变化,他们将使用相同的端点来执行其后续查询。
您仍将使用相同的数据库控制器来收集和组织数据。您将以不同的方式将它们“连接”在一起,但大的、合乎逻辑的部分仍然是相同的。
  
响应区别
使用 REST API,您的客户端始终会收到结构一致的有效负载。
在设计 API 时,您决定在每个端点上公开哪些字段以及如何构建数据。作为以用户为中心的开发人员,您会考虑如何最好地对数据进行分组,以及是否需要针对特定​​用例的新路由。创建这些新端点可为您的用户提供数据的全新视图。
客户可能会针对他们发现的您没有预料到的问题请求自定义路由。您需要决定是否足够重要以进入您的待办事项或允许用户开发他们自己的解决方案。
然而,GraphQL 响应完全匹配请求的结构。客户可以设计他们想要的数据的确切范围和形式。这种方法减少了过度获取(给客户端太多)和获取不足(要求您的客户端进行多次调用)的问题。这种更灵活的过程还允许开发人员专注于新字段和数据,而无需猜测客户想要什么。
  
创建文档区别
在开发 API 时,您可能会发现自己将文档编写工作拖到了流程的最后。
但是,首先编写文档可能是有益的。这种方法有助于减少文档过时的情况,并确保您继续构建相关功能。
另一种方法将文档作为工单中的最终任务,确保最新的示例和文档。在开发 REST API 时,使用这样的策略可以使您的文档保持相关性并为您的用户提供帮助。
GraphQL 采用了一种稍微不同的方法。
作为一个类型化的 API,GraphQL 是有效的自文档化。您可以允许您的客户访问 GraphQL 游乐场以探索 API 以及可用的变更和查询。当您更新 API 时,这些类型会同时更新。
由于这不是一个单独的过程,因此您可以更加相信开发团队保持 GraphQL 文档最新的能力。
 
缓存
由于 GraphQL 全部来自单一路由,因此远离服务器的缓存策略更具挑战性。虽然存在一些产品,但没有那么多记录良好的、开箱即用的解决方案。
对于基于 REST 的 API,您可以提供基于路由的缓存层以减少服务器和数据库负载。这些策略得到了很好的部署,并且长期以来一直是行业标准做法。GraphQL 在这方面有一些追赶。
 

  • 何时选择 REST 

REST 是一种久经沙场的解决方案,可提供当今的大部分 Web 功能。它可能不是最新和最伟大的技术,但是这匹主力可以完成工作。
通常,当应用程序以可预测和可理解的方式请求您的数据时,REST 是正确的选择。如果您正在构建的工具可能与其他工具(例如低代码平台)集成,那么 REST 通常是更好的解决方案。Bubble、Zapier 和其他公司为与基于 REST 的 API 集成提供了良好的支持。
  • 何时选择 GraphQL 

GraphQL 的受欢迎程度正在迅速增加,尤其是在前端开发人员中。
如果您的数据是灵活的,并且可以通过多种不同且不可预测的方式进行查询,例如使用 CMS,那么 GraphQL 可能是更好的选择。
允许您的用户做出决定,而不是试图预测他们希望您的应用程序如何呈现数据和公开各种字段。让他们控制你的文档齐全的 API。
 
REST 稳定且众所周知的架构提供了熟悉度,并使开发人员能够快速提高工作效率。GraphQL 灵活且自文档化,允许用户使用根据其特定需求定制的 API。