主要速率限制
默认禁用 GitHub Enterprise Server 的速率限制。 请与站点管理员联系,以确认实例的速率限制。
如果你是网站管理员,可以为实例设置速率限制。 有关详细信息,请参阅“配置速率限制”。
如果要为实例外部的用户或组织开发应用,则应用标准 GitHub 速率限制。 有关详细信息,请参阅 GitHub Free 文档中的“GraphQL API 的速率限制和查询限制”。
节点限制
若要通过架构验证,所有 GraphQL API 调用都必须满足以下标准:
计算调用中的节点
下面两个示例显示如何计算调用中的节点总数。
-
简单查询:
query { viewer { repositories(first: 50) { edges { repository:node { name issues(first: 10) { totalCount edges { node { title bodyHTML } } } } } } } }
计算:
50 = 50 repositories + 50 x 10 = 500 repository issues = 550 total nodes
-
复杂查询:
query { viewer { repositories(first: 50) { edges { repository:node { name pullRequests(first: 20) { edges { pullRequest:node { title comments(first: 10) { edges { comment:node { bodyHTML } } } } } } issues(first: 20) { totalCount edges { issue:node { title bodyHTML comments(first: 10) { edges { comment:node { bodyHTML } } } } } } } } } followers(first: 10) { edges { follower:node { login } } } } }
计算:
50 = 50 repositories + 50 x 20 = 1,000 pullRequests + 50 x 20 x 10 = 10,000 pullRequest comments + 50 x 20 = 1,000 issues + 50 x 20 x 10 = 10,000 issue comments + 10 = 10 followers = 22,060 total nodes
查询优化策略
- 限制对象数量:对
first
或last
参数使用较小值,并对结果分页。 - 减少查询深度:除非必要,否则请避免请求深度嵌套对象。
- 筛选结果:使用参数筛选数据并仅返回所需内容。
- 拆分大型查询:将复杂查询拆分为多个更简单的查询。
- 仅请求必填字段:仅选择所需字段,而不是请求所有可用字段。
通过遵循这些策略,可以降低达到资源限制的可能性,并提高 API 请求的性能和可靠性。