永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
悄悄名不副实的“无限”方案带来的问题
“无限”这个词出现在许多 API 价格页面上，却很少名副其实。滚动到某些“无限”套餐的细则部分，您会发现一项合理使用政策、一个软上限，或者一条保留对超出服务商预期使用量的账户进行限流的权利的条款。那不是无限。那是一个服务商还没有告诉您具体数字的限制。
这很重要，因为“无限”本应是您专门为了不再担心限制而购买的套餐。如果客户注册了一个“无限”档位，随后却收到支持团队的邮件，要求其减少用量，那么这个词就在它唯一的使命上失败了。这不是技术上的失败，而是措辞问题，而价格页面上的措辞问题损失的不仅是金钱，还有信任。
我们的 Unlimited 密钥每月 €50，没有请求上限。我们不会保留依据某个未公布的数字对其进行限流的权利，因为公布这个数字，正是把某样东西称为无限的全部意义所在。如果我们真的需要一项防止滥用的技术保障措施，我们会直截了当地说明并告诉您具体数字，而不是把一个软上限藏在一个承诺恰恰相反的词语背后。
这在一定程度上取决于基础设施的实际运作方式。查询时区或解析 IP 地址的请求，计算成本非常低，而且这一成本不会因为当月有多少其他“无限”客户而改变。基于真实单次请求成本构建的套餐，确实可以做到不设上限，因为服务商并没有试图用固定的月费去平摊来自共享资源池的不可预测用量。而一个暗中依赖大多数“无限”客户使用量远低于其应得额度的套餐，一旦遇到真正大量使用的客户就难以为继，而这恰恰是“无限”这个词本应服务的客户。
这里还涉及配额透明度的问题。My Geocode 的每个响应都带有响应头，显示您的配额限制、已使用量和剩余量，以及您的剩余额度。如果像“无限”这样的词做的事情与其字面意思不符，这些响应头最终会暴露出来，因为被限流的请求与正常请求看起来不一样。我们更希望这些响应头始终印证这个词最直白的含义。
这一切并不是在抱怨上限本身。一个提供明确标明上限套餐的服务商，比如以固定价格每月提供固定数量的请求，是诚实的，客户可以围绕这个数字进行规划。问题出在那些借用“无限”一词的营销分量、却在实际运营中食言的套餐。可以叫它大容量套餐，可以叫它高级档位。只是不要称它为“无限”，除非客户可以按照自己产品的需要尽情使用，并且永远不会听到相反的说法。