永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
速率限制应该写在文档里，而不是靠用户自己去发现
有一种特别糟糕的早晨：以大量请求失败开始，以开发者第一次阅读服务商的状态页面结束，试图弄清楚这些失败是服务中断，还是一个他们从来不知道存在的限制。这样的早晨完全可以避免，而它在这个行业中仍然时有发生，这是文档的失败，而不是基础设施的失败。
速率限制不是秘密。它是关于一个系统的运行事实，就像最大请求大小或支持的 HTTP 方法一样，应该放在同样的地方：在任何人触及它之前就写清楚。我们在速率限制文档中公布了我们的限制，与身份验证和错误页面放在一起，这样开发者在编写第一行集成代码之前，就能拿到需要据以规划的数字，而不是在经历了第一个像服务中断一样的下午之后。
不过，仅有文档是不够的，因为限制可能取决于您使用的方案，而一旦您的账户状态发生变化，文档就过时了。这就是为什么每个响应还携带实时的配额响应头：您的上限、已用量、剩余免费配额、您所在网络的共享配额已用量、剩余预付额度，以及配额何时重置。您无需把文档与控制台对照，就能知道自己所处的状态。答案会随响应本身一起返回，每一次调用都是如此。
有些服务商把公开限制视为需要隐藏的竞争弱点，理由是一个可见的数字会促使客户压价，或者拿去与竞争对手比较。我们认为这种直觉恰恰相反。一个没人能看到的限制，并不能更好地保护服务商的基础设施。它只意味着客户第一次得知真实数字时，已经超出了限制，而这对一个成长中的产品来说是最糟糕的时刻，而且就发生在他们自己的用户面前。
提前在文档中写明限制，还会迫使服务商遵守一种设计纪律。如果速率限制要公开，它就必须是一个有人愿意为之负责的真实数字，而不是一个模糊的内部阈值，每当不方便时就被悄悄调整。把数字写下来，并在每次调用的响应头中给出，意味着这个限制必须真正就是限制，而且始终如一，而这正是开发者需要它具备的特性。
在生产环境中通过失败的请求发现速率限制，并不是必经的成长仪式，而是文档没有尽到职责的信号。我们的文档旨在让那种特别糟糕的早晨成为您在别人身上读到的故事，而不是发生在您自己身上的事。