永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么我们按请求而不是按席位定价
席位是一种您安装一次、每天早上打开的软件单位。API 调用不是这样。每当批处理任务运行、结账页面加载，或后台工作进程解析一个收货地址时，它就会发生。没有人坐在桌前一天点一万次按钮。这是机器在做的事，而且是突发式地做。
按席位定价之所以存在，是因为它容易销售、容易预测。您数一下人数，乘以月费，就得到一个财务部门可以据此做计划的数字。这适用于人们登录使用的软件。它不适用于由机器调用的基础设施，因为团队的人数与该团队系统发出的请求数几乎没有关系。
我们对 My Geocode 按请求定价，因为这才是我们提供服务的真正成本所在。每次查询都会访问数据库、进行一些计算并返回响应。成本随用量增长，而不是随持有 API 密钥的工程师人数增长。所以我们按用量收费：任何地址每天 2,500 次免费请求，完全不需要密钥。当您需要更多时，用电子邮件地址注册，然后以每次请求 €0.0001 的价格充值预付额度，或者以每月 €50 的价格获取 Unlimited 密钥。每个端点和每个兼容替换主机的价格都相同。
这也消除了按席位定价所造成的一种奇怪激励。按席位付费时，您会忍不住让整个团队共用一个登录账号来省钱，而这通常本来就违反服务条款。按请求付费时，没有什么需要共用的。一个密钥还是十个密钥，都无所谓。重要的是您实际进行了多少次查询，而这个数字是真实的。您的产品更繁忙时它就上升，不忙时就下降，无需任何人重新谈判合同。
按请求定价还能干净地向下缩放，而按席位定价很少做到这一点。一个学生项目或周末原型不需要五个席位。它每月需要几百次查询，免费配额就能覆盖，无需任何销售沟通。一个成长中的产品不需要猜测它的地理编码需要多少个席位；它需要知道一千次请求的费用是多少，这个数字可以直接放进单位经济模型的电子表格里。
这并不意味着按请求定价没有取舍。它意味着您的账单会随流量变动，如果您没有关注用量，这可能会让人不安。这是一个真实的代价，我们不会假装不是。这正是为什么每个响应都带有配额响应头，让您总能在账单让您吃惊之前，而不是之后，知道自己的用量状况。
我们并不反对席位这个概念。对于由固定数量的人打开和关闭的工具，它是合理的。地理编码不是那种工具。它更像电力而不是订阅：由运行您业务的机器消耗，消耗速度与您的员工人数毫无关系。按实际使用单位定价，是唯一有意义的定价方式。