缓存

提供对象标识符允许客户端构建丰富的缓存

在基于端点的 API 中，客户端可以使用 HTTP 缓存来轻松避免重新获取资源，并用于识别两个资源是否相同。这些 API 中的 URL 是一个 **全局唯一标识符**，客户端可以利用它来构建缓存。然而，在 GraphQL 中，没有类似 URL 的原语为给定对象提供此全局唯一标识符。因此，最佳实践是 API 公开此类标识符供客户端使用。

全局唯一 ID#

一种可能的模式是保留一个字段，例如 id，作为全局唯一标识符。这些文档中使用的示例模式使用这种方法

这是一个强大的工具，可以交给客户端开发人员。与基于资源的 API 的 URL 提供全局唯一键的方式相同，此系统中的 id 字段提供了全局唯一键。

如果后端使用 UUID 之类的东西作为标识符，那么公开此全局唯一 ID 可能非常简单！如果后端还没有为每个对象提供全局唯一 ID，则 GraphQL 层可能需要构建它。通常，这就像将类型的名称附加到 ID 并将其用作标识符一样简单；然后，服务器可以通过对其进行 base64 编码来使该 ID 不透明。

可选地，此 ID 可以用于与 全局对象标识 的 node 模式一起使用。

与现有 API 的兼容性#

使用 id 字段用于此目的的一个问题是，使用 GraphQL API 的客户端将如何与现有 API 协同工作。例如，如果我们现有的 API 接受特定于类型的 ID，但我们的 GraphQL API 使用全局唯一 ID，那么同时使用两者可能会很棘手。

在这些情况下，GraphQL API 可以将先前 API 的 ID 公开在单独的字段中。这让我们两全其美

• GraphQL 客户端可以继续依赖一致的机制来获取全局唯一 ID。
• 需要使用我们之前 API 的客户也可以从对象中获取 previousApiId 并使用它。

备选方案#

虽然全局唯一 ID 在过去被证明是一种强大的模式，但它们并不是唯一可用的模式，也不是适合所有情况的模式。客户端真正需要的关键功能是能够为其缓存推导出全局唯一标识符。虽然让服务器推导出该 ID 可以简化客户端，但客户端也可以推导出该标识符。通常，这就像将对象的类型（使用 __typename 查询）与某个类型唯一的标识符组合起来一样简单。

此外，如果用 GraphQL API 替换现有 API，如果 GraphQL 中的所有字段都相同，除了 id，它已更改为全局唯一，这可能会令人困惑。这将是选择不使用 id 作为全局唯一字段的另一个原因。