如何在 GraphQL 中对“索引”列表与“显示”详细信息进行建模？答案

【问题标题】：How to model "index" list vs "show" details in GraphQL?如何在 GraphQL 中对“索引”列表与“显示”详细信息进行建模？
【发布时间】：2017-03-12 14:02:19
【问题描述】：

我的数据模型有两个资源：Folder 和 Messages。每条消息都属于一个文件夹。有时我会想要获取文件夹列表（包括每个文件夹的一些字段）。有时我会想要获取特定文件夹的详细信息（包括该文件夹的一些字段和消息）。

在 Rails/RESTful 系统中，这将对应于 Folder 资源上的 index 和 show 操作；后者将接收指定所需文件夹的id 参数。这个模式在“惯用的”GraphQL 中会是什么样子？

一种方法可能是每个操作都有一个字段：

type Query {
  folders: [Folder]
  folder(id: String!): Folder
}

这里有一些重复，看起来很混乱，使客户更难自省和理解架构。

也许可以使用可为空的参数删除重复项：

type Query {
  folder(id: String): [Folder]
}

如果传递了id，则只会返回Folder 的详细信息（作为一项数组）。如果id 是nil，那么它将获取所有文件夹的详细信息。这种重载似乎增加了一些隐藏的复杂性。

哪种方法是“更好的做法”？有没有更好的方法来模拟这种情况？

【问题讨论】：

对此有何回顾？我有很多模型，其中将使用详细视图和列表视图。我完全支持方法 2，因为它实现起来更简单，并且将架构保持一半大小。是否出现了任何问题，例如客户期望的详细路线但未找到？

【解决方案1】：

TLDR：字段很便宜，使用它们。

我建议第一种方法。以同样的方式，一个 REST API 可以毫无希望地被标志混淆以触发不同的行为，具有各种参数的字段也是如此。通过制作两个不同的字段，还可以让类型系统给予更强的客户端保证：

type Query { folders: [Folder!]! folder(id: String!): Folder }

在这种情况下，您总会得到某种folders 的列表，它不会包含任何nulls。空性只是空的列表。 API 文档本身，如果您尝试将越来越多的可选参数混合到一个字段中，情况可能并非如此。

此外，如果您需要对 folders 进行分页，则需要该端点的分页特定参数，可能还需要 connection pattern 的中间结构。

【讨论】：

【解决方案2】：

我使用第二种方法。通过这种方式，您可以稍后将更多参数添加到同一端点。也许一个文件夹有一个路径，或者你想过滤创建日期。

【讨论】：