避免轮询
您应该订阅 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 的结构，这会导致您的集成中断。相反，您应该查找包含您需要的信息的字段。例如，创建问题的端点返回一个 html_url 字段，其值为 https://github.com/octocat/Hello-World/issues/1347，以及一个 number 字段，其值为 1347。如果您需要知道问题的编号，请使用 number 字段，而不是解析 html_url 字段。
同样，您不应该尝试手动构建分页查询。相反，您应该使用链接标头来确定您可以请求哪些结果页。有关更多信息，请参阅“在 REST API 中使用分页”。
在适当的情况下使用条件请求
大多数端点返回 etag 标头，许多端点返回 last-modified 标头。您可以使用这些标头的值来发出条件请求。如果响应没有改变，您将收到 304 Not Modified 响应。如果返回 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 错误。
故意忽略重复的验证错误可能会导致您的应用程序因滥用而被暂停。