使用 REST API 的最佳做法

避免轮询

应订阅 Webhook 事件，而不是通过轮询 API 来获取数据。这有助于将集成保持在 API 速率限制内。有关详细信息，请参阅“Webhook 文档”。

GitHub 在资源发生移动时会通过提供重定向状态代码来明确告诉您。您应该遵循这些重定向。每个重定向响应都使用要转到的新 URI 来设置 Location 标头。如果您收到了重定向，最好更新代码以遵循新的 URI，以防您请求我们可能已删除的无效路径。

我们提供了 HTTP 状态代码列表，你在设计应用以遵循重定向时需要注意这些代码。

通常，API 响应包含 URL 形式的数据。例如，当请求存储库时，我们会发送一个名为 clone_url 的键，其中包含可用来克隆存储库的 URL。

为了应用程序的稳定性，您不应该尝试解析此数据，或者尝试猜测并构造未来 URL 的格式。否则，如果我们决定更改该 URL，您的应用程序可能会中断。

例如，在处理分页结果时，人们往往很想构造在末尾追加 ?page=<number> 的 URL。要抑制这种冲动。有关可靠跟踪分页结果的详细信息，请参阅“在 REST API 中使用分页”。

GitHub API 速率限制可确保 API 速度快且可供每个人使用。

如果达到速率限制，则应该在 x-ratelimit-reset 标头指定的时间之后再发出请求。否则，可能会导致集成被禁用。有关详细信息，请参阅“REST API 中的资源”。

GitHub 可能还会使用辅助速率限制来确保 API 可用性。有关详细信息，请参阅“REST API 中的资源”。

为了避免达到此限制，应确保您的应用程序遵循以下准则。

发出经过身份验证的请求，或使用应用程序的客户端 ID 和密钥。未经身份验证的请求会受到更严格的二级速率限制。
依次为单个用户或客户端 ID 发出请求。不要同时为单个用户或客户端 ID 发出多个请求。
如果你要为单个用户或客户端 ID 发出大量的 POST、PATCH、PUT 或 DELETE 请求，则每两个请求之间至少应间隔一秒钟。
如果已受到限制，请等待，然后再重试请求。
- 如果 Retry-After 响应标头存在，请在标头中指定的时间后重试请求。 Retry-After 标头的值始终为整数，表示你在再次发出请求之前应等待的秒数。例如，Retry-After: 30 表示你在发出更多请求之前应等待 30 秒。
- 如果 x-ratelimit-remaining 标头为 0，请在 x-ratelimit-reset 标头指定的时间之后再重试请求。 x-ratelimit-reset 标头始终是一个整数，表示当前速率限制窗口重置的时间（单位为 UTC 纪元秒）。
- 否则，请在两次重试之间等待一段呈指数级增长的时间，并在重试特定次数后引发错误。

GitHub 保留根据需要更改这些准则以确保可用性的权利。

尽管您的代码从未引入漏洞，但您可能会发现在尝试访问 API 时遇到连续错误。

你应该确保与 API 正确交互，而不是忽略重复的 4xx 和 5xx 状态代码。例如，如果某个终结点请求一个字符串，而你向其传递一个数值，则你将会收到 5xx 验证错误，并且你的调用不会成功。同样，试图访问未经授权或不存在的终结点会导致 4xx 错误。

故意忽略重复的验证错误可能会导致您的应用程序因滥用而被暂停。