REST 比 GraphQL 更适合的项目？

Question

根据我阅读的文章，GraphQL 在往返方面更节省资源，它还可以完成 REST 可以提供的功能。鉴于 Web 应用程序只是从头开始，软件架构师和开发人员可能决定继续使用 REST 而不是 GraphQL 的原因是什么？还考虑到这是一个持续的项目，将从 Web 和移动设备中使用并且需要 openID 连接。

Answer 1

可能有多种原因。我认为这是非常主观的，但对我来说它基于：

REST 是古老而稳定的方式。它被大多数人使用，并为 API 消费者提供了一个简单的界面。因为它很旧（绝不是坏事）大多数开发人员都知道它并且知道如何使用它。

GraphQL 是镇上的新人。它确实为大多数系统节省了一些性能（往返和有效负载），但确实改变了我们对后端的看法。它不提供资源端点，而是提供数据模型图，让消费者决定要获取的数据。

截至 "new guy"，GraphQL 尚未经过实战测试。它对大多数人来说都是新的，因此基本上没有被其他人、先行者和初创公司采用。

但同样，这是一个带有主观答案的主观问题。目前我正在为一家初创公司使用 GraphQL 来测试它的耐用性，看看它是否能解决我们的需求。到目前为止，它确实如此。如果您要决定是使用 REST 还是 GraphQL 开始一个新项目，您应该考虑您的需求以及您想要花多少 money/time 来学习新事物与做您所知道的并更快地实现目标.

Answer 2

这是一个相当广泛的问题，但我会根据自己的经验尝试回答。

REST 提供对特定资源的访问，例如用户或产品。请求的结果可能是假设您将需要或使用的数据，即无论您是否使用所有数据，它都可能是关于该资源的所有内容。

还有N+1的问题。以用户拥有和属于多个关系场景为例；使用 RESTful API 你会向用户发出请求，例如/users/:id 然后向他们所有的关系提出请求，例如/users/:id/relationships，所以这已经是两个请求了。关系端点可能有一个假设以在结果数组中包含关系（朋友、家庭成员等）和用户，但如果 API 没有如果不做那个假设，您将不得不向每个用户端点发出请求以获取每个关系中每个用户的数据。

这个例子还可以更深入；如果您想要所有二线关系（例如朋友的朋友）怎么办？

GraphQL 通过允许您明确询问您需要什么来解决这个问题。您可以构造一个查询 return 深度的数据：

query myQuery($userId: ID!) {
  user(id: $userID) {
    id
    name
    relationships {
      id
      type
      user {
        id
        name
        relationships {
          id
          type
          user {
            id
            name
          }
        }
      }
    }
  }
}

Fragments 可以稍微清理一下，并且可能存在递归问题，但您应该明白了；一个请求即可获得所需的所有嵌套数据。

如果您不太需要此类嵌套或互连的结果集，GraphQL 可能不会在收益和复杂性之间提供太多的权衡。

但是，我发现 GraphQL 的最大好处之一是它的可扩展性和自我文档化。

Answer 3

在我看来，除其他方面外，这也是一个用例问题：

如果您的应用程序或其他连接速度较慢的前端 and/or 具有高延迟（典型示例：移动应用程序），GraphQL 的“往返最小化”可能是一个很大的优势。并且让客户端控制数据结构非常方便，因此通常可以减少所需的 API 个端点的数量。
如果是服务器之间的数据交换，RESTful APIs 与 HTTP 密切相关这一事实具有动词语义等优势（GraphQL 无法提供，因为您执行一个 GraphQL 查询的多个操作）和状态代码。另外：您可以免费获得所有 HTTP 缓存功能，这在大量数据驱动中非常重要 applications/services。此外，REST 无处不在（尽管可能大多数 API 被宣传为“RESTful”，但通常是因为缺少对超媒体的支持）。

REST 比 GraphQL 更适合的项目？

Projects where REST is more suitable over GraphQL?

architecture

rest

web-applications

graphql