API
速率限制
API 使用漏桶算法对请求进行速率限制。每个请求会消耗一定数量的单位，这些单位以恒定速率从桶中漏出。这样既能保持流量平稳，又允许短时间的突发请求。
GraphQL API
GraphQL API 的速率限制基于每个请求的成本，而不是固定的请求数量。下面各节介绍了降低成本的最佳实践，以及如何读取您当前的速率限制状态。
最佳实践
- 使用订阅而不是通过查询轮询，来了解数据何时发生变化。
- 只查询您需要的字段，并使用
filter缩小列表查询的范围。 - 列表查询每页最多返回 100 条记录，但较大的页面成本高于较小的页面。一次请求获取 100 条记录的成本高于获取 10 条，因此请尽量请求较少的记录。详情请参见分页。
- 如果请求因
429错误被拒绝，说明您的桶已满。请停止发送请求，并且只在reset给出的时间过后再发出新请求。
速率限制
为了保护 API 免受过于复杂或资源消耗过大的查询影响，每个请求都会根据所请求的数据量分配一个成本。对有效请求或未通过业务验证的请求的每个响应，都包含一个 extensions.cost 对象，其中有该请求的成本和您的速率限制状态。当请求未通过 GraphQL schema 验证时，该对象会被完全省略。
cost· Integer- 当前请求的成本，以单位计。
limit· Integer- 当前速率限制窗口内允许的最大成本，以单位计。
used· Integer- 此窗口内已消耗的单位数。
remaining· Integer- 在达到限制之前您还可使用的单位数。
reset· Integer- UNIX 时间戳，以秒为单位，表示配额何时刷新。
REST API
REST API 的速率限制适用于瓦片服务。与 GraphQL API 不同，速率限制状态通过 HTTP 响应头返回，并且每个请求的成本固定为 1 个单位。每个请求（包括失败的请求）都会返回这些响应头。
x-ratelimit-cost· Integer- 当前请求的成本，以单位计。对于 REST 请求始终为
1。 x-ratelimit-limit· Integer- 当前速率限制窗口内允许的最大成本，以单位计。
x-ratelimit-used· Integer- 此窗口内已消耗的单位数。
x-ratelimit-remaining· Integer- 在达到限制之前您还可使用的单位数。
x-ratelimit-reset· Integer- UNIX 时间戳，以秒为单位，表示配额何时刷新。
当前限制
速率限制按客户应用，窗口为一分钟。目前尚未设置默认限制。在 2027 年引入默认限制之前，限制按客户单独配置。
某些查询和变更还有单独的限制，低于您的总体限制。这些限制按产品设置，有时按请求设置，而不是全局设置。
此内容是否有帮助？