避免轮询
您应该订阅 Webhook 事件，而不是轮询 API 以获取数据。这将有助于您的集成保持在 API 速率限制内。更多信息，请参见“Webhook 文档”。
进行身份验证请求
经过身份验证的请求比未经身份验证的请求具有更高的主要速率限制。为避免超过速率限制，您应该进行身份验证请求。更多信息，请参见“REST API 的速率限制”。
避免并发请求
为避免超过次要速率限制，您应该按顺序而不是并发地发出请求。为此，您可以为请求实现队列系统。
在更改请求之间暂停
如果您正在发出大量的 `POST`、`PATCH`、`PUT` 或 `DELETE` 请求，请在每个请求之间至少等待一秒钟。这将有助于您避免次要速率限制。
正确处理速率限制错误
如果您收到速率限制错误，则应根据以下准则暂时停止发出请求
- 如果存在 `retry-after` 响应头，则您应该在经过这么多秒后才能重试您的请求。
- 如果 `x-ratelimit-remaining` 头为 `0`，则您应该在 `x-ratelimit-reset` 头指定的时间之后才能发出另一个请求。`x-ratelimit-reset` 头以 UTC 纪元秒为单位。
- 否则，请等待至少一分钟后再重试。如果您的请求由于次要速率限制而继续失败，请在重试之间等待指数增加的时间量，并在特定数量的重试后抛出错误。
在您受到速率限制时继续发出请求可能会导致您的集成被禁止。
遵循重定向
GitHub REST API 在适当情况下使用 HTTP 重定向。您应该假设任何请求都可能导致重定向。接收 HTTP 重定向不是错误，您应该遵循重定向。
`301` 状态代码表示永久重定向。您应该将请求重复到 `location` 头指定的 URL。此外，您还应该更新您的代码以将此 URL 用于未来的请求。
`302` 或 `307` 状态代码表示临时重定向。您应该将请求重复到 `location` 头指定的 URL。但是，您不应该更新您的代码以将此 URL 用于未来的请求。
根据 HTTP 规范，可以使用其他重定向状态代码。
不要手动解析 URL
许多 API 端点在响应正文中的字段中返回 URL 值。您不应该尝试解析这些 URL 或预测未来 URL 的结构。如果 GitHub 将来更改 URL 的结构，这可能会导致您的集成中断。相反，您应该查找包含您需要的信息的字段。例如，创建问题的端点返回一个值为 `https://github.com/octocat/Hello-World/issues/1347` 的 `html_url` 字段和一个值为 `1347` 的 `number` 字段。如果您需要知道问题的编号，请使用 `number` 字段，而不是解析 `html_url` 字段。
同样，您也不应该尝试手动构建分页查询。相反，您应该使用链接头来确定您可以请求哪些结果页。更多信息，请参见“在 REST API 中使用分页”。
在适当情况下使用条件请求
大多数端点返回 `etag` 头，许多端点返回 `last-modified` 头。您可以使用这些头的值来发出条件请求。如果响应没有更改，您将收到 `304 未修改` 响应。如果返回 `304` 响应，则发出条件请求不会计入您的主要速率限制。
例如，如果之前的请求返回 `etag` 头值为 `644b5b0155e6404a9cc4bd9d8b1ae730`，则您可以在将来的请求中使用 `if-none-match` 头
curl https://api.github.com/meta --include --header 'if-none-match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
例如，如果之前的请求返回 `last-modified` 头值为 `Wed, 25 Oct 2023 19:17:59 GMT`，则您可以在将来的请求中使用 `if-modified-since` 头
curl https://api.github.com/repos/github/docs --include --header 'if-modified-since: Wed, 25 Oct 2023 19:17:59 GMT'
不要忽略错误
您不应该忽略重复的 `4xx` 和 `5xx` 错误代码。相反，您应该确保您正在正确地与 API 交互。例如，如果端点请求字符串而您传递的是数值，您将收到验证错误。同样，尝试访问未授权或不存在的端点将导致 `4xx` 错误。
故意忽略重复的验证错误可能会导致您的应用因滥用而被暂停。