在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
以正确的方式重试失败的查询
自动重试对某些错误是正确的做法，对另一些错误则是浪费请求。处理不当，要么会让本已吃力的端点被请求淹没，要么会放弃一个一秒钟后本可以成功的查询。
值得重试的错误
503 响应表示服务暂时不可用，这正是短暂延迟后重试所要应对的那种临时状况。您这一端的网络超时，也就是根本没有收到任何响应，也属于同一类，因为请求可能已被处理，也可能没有。
HTTP/1.1 503 Service Unavailable
{
"status": "error",
"error": {"code": "service_unavailable", "message": "Temporarily unavailable, try again shortly"}
}不值得重试的错误
400 表示请求本身格式有误，例如缺少必需参数或坐标超出范围。401 表示身份验证失败。在不解决根本问题的情况下重试这两种错误，只会再次产生同样的错误，而且在大多数情况下每次尝试仍计为一次请求，因此针对错误请求的重试循环可能会白白耗尽您的配额。
在两次尝试之间退避
对于单次交互式查询，固定的短暂延迟就可以了；但重试大量失败项的批处理任务应当逐步退避，把两次尝试之间的等待时间加倍，直到一个合理的上限，这样短暂的中断就不会在服务恢复的那一刻变成一波重试洪流。
429 是单独的一种情况
429 与其说是需要重试的失败，不如说是需要暂停的信号。请读取 X-Quota-Reset 响应头并等到那个时间，而不是以固定的短暂延迟重试，因为在重置之前重试只会一次又一次地产生同样的 429。
牢记请求成本
每一次到达服务器的重试尝试，无论成功与否，都是一次请求。一个尊重临时错误与永久错误之区别的重试策略，能让您的每日配额和预付额度花在真正的工作上，而不是反复的失败上。
区分“再试一次”和“先解决这个问题”，基本上就是一个好的重试策略的全部要义。错误页面列出了 API 返回的所有错误代码及各自的触发原因。