永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
“无限请求”确切地应该意味着什么
“无限”这个词有着精确的含义，但它被随意使用的频率之高，以至于期待它的精确含义几乎显得有些天真。它应该完全名副其实：在该套餐下，无论您的实际用量达到什么速率，您可以发送的请求数量都没有上限。它不应该意味着一个服务商没有公开的很大的数字，不应该意味着用量超过某个内部阈值后就会被限速，也不应该意味着一个在技术上没有明示限制、却附带一条实际上起着未公开限制作用的合理使用条款的套餐。
我们的 Unlimited 密钥每月 €50，意味着第一种定义，而且只意味着第一种定义。没有任何内部阈值，一旦超过就开始限速请求；没有用合理使用政策来代替一个我们不愿公开的数字；也不存在套餐宣传的内容与您大量使用时实际允许的内容之间的差别。如果我们将来真的加入了某种真正的技术保护措施，诚实的做法应该是给套餐改名并公布真实的数字，而不是保留这个词，再悄悄给它附加条件。
我们认为，检验一个无限声明是否真实的有用标准，是看它能否以一种具体、可核查的方式被证伪：客户能否在短时间内发送异常大量的请求，看看套餐是否真的撑得住；还是服务商在某处留有措辞，允许他们在事后重新定义什么叫“异常”，而这种定义是客户无法从套餐条款中预见的。一个在事后总能被解释过去的声明，并不是真正的声明。它只是一个占位符，内容由服务商日后决定。
这种区别之所以重要，是因为无限套餐正是为那些需要不再把请求量当作一项需要管理的成本来考虑的客户而存在的。这就是它的全部价值所在：支付固定金额，不再计数。一个悄悄仍然设有上限的套餐，以最糟糕的方式违背了这个初衷，因为专门为了不再担心限制而购买它的客户，恰恰最有可能在隐藏的上限被执行时大吃一惊，因为他们正是最依赖这个词名副其实的人。
我们并不是说每家服务商都需要提供无限套餐，也不是说一个有上限、定价清晰的套餐比无限套餐更差。一个明确说明的上限，本身就是诚实的。不诚实的是，因为上限设得足够高，大多数客户永远不会亲自触及，就把一个有上限的套餐称为无限。这个词应该描述套餐的一种属性，在任何用量下都经得起检验、确实成立，而不是一种碰巧对中等客户成立、却在任何真正需要这个承诺字面兑现的人面前悄然失效的营销印象。