设计响应类型

查询和更新响应类型的最佳实践

更新的响应类型

💡 提示

这种响应类型模式对于更新是有用的，因为它们可能导致许多有效的失败状态（例如尝试删除不存在的对象）。

例如，假设我们有一个电子商务图。在执行 结账 更新时，如果购买的商品缺货或买家资金不足，该更新可能会失败。

如果我们定义一组 ErrorResponse 类型，前端开发者可以根据出现的失败类型提供定制化体验：

1
interface MutationResponse {
2
  status: ResponseStatus!
3
}
4

5
type CheckoutSuccess implements MutationResponse {
6
  status: ResponseStatus!
7
  cart: [Product!]!
8
  invoice: Invoice!
9
}
10

11
interface ErrorResponse {
12
  status: ResponseStatus!
13
  message: String!
14
}
15

16
type CheckoutError implements ErrorResponse {
17
  status: ResponseStatus!
18
  message: String!
19
}
20

21
union CheckoutResponse = CheckoutSuccess | CheckoutError
22

23
type Mutation {
24
  checkout(cart: ID!): CheckoutResponse!
25
}

查询的响应类型

假设我们有一个基本的 GraphQL API，它定义了以下 Query 类型：

1
type Query {
2
  users: [User!]!
3
}

此 Query.users 字段很直观：如果你查询它，你会得到一个 User 对象的列表。然而，这个返回类型并没有提供任何有关结果的信息：

如果列表为空，这是因为在用户数为零，还是发生了错误？
即使列表有数据，API 是否返回了所有用户，还是只是子集？
是否有多页结果？

为了回答这些类似的问题，对于查询层的字段返回 "包装" 对象可能很有帮助，这些对象可以包含操作结果以及执行操作的元数据。例如，在你需要分页结果或实现 Relay-style 连接的模式时，这种模式可能会有所帮助。

示例：`UsersResponse`

以下示例为我们的 Query.users 字段定义了 UsersResponse 类型：

1
type User {
2
  id: ID!
3
  firstName: String!
4
  lastName: String!
5
}
6

7
type UsersResponse {
8
  offset: Int!
9
  limit: Int!
10
  totalResults: Int!
11
  data: [User!]!
12
}
13

14
type Query {
15
  users(limit: Int = 10, offset: Int = 0): UsersResponse!
16
}

通过此更改，客户端的查询可以指定每页有多少结果，从哪一页开始，并了解可以进行分页的总结果数：

1
query FetchUsers {
2
  users(limit: 20, offset: 0) {
3
    totalResults
4
    data {
5
      id
6
      firstName
7
      lastName
8
    }
9
  }
10
}

下一条

首页

设计响应类型

查询和更新响应类型的最佳实践

查询的响应类型

示例：UsersResponse

示例：`UsersResponse`