永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
我们为什么按自己想要购买的方式来打造它
我们构建并运营一个地理编码 API。这就是公司的全部。这些文章中描述的每一个决定，包括按请求计费而不是按席位计费、无需密钥的免费档而不是倒计时试用、兼容主机而不是专有格式、每个响应都带配额响应头而不是有延迟的控制台，都可以追溯到我们在打造它时反复使用的同一个简单标准：如果我们是另一端的客户，这会不会让我们恼火。
我们在这一系列文章中写到的大多数坏习惯，只要真正想象一下自己是为之付费的人，就一下子过不了这一关。没有人想通过生产环境中一次失败的请求才发现速率限制。没有人想要一个结果附带了合理使用政策的“无限”方案。没有人想要一次耗时一个季度的迁移，只因为前一家服务商的 SDK 多年来把它的数据结构散布在整个代码库中。这些都不是冷门的抱怨。几乎每个开发者都曾在 API 关系的另一端经历过它们，这也正是为什么我们认为，不需要做客户调研就能认定这些是值得避免的问题。
价格是应用这一标准最明显的地方。任何地址每天 2,500 次免费请求，完全不需要密钥。需要更多时，用电子邮件地址注册，然后按每次请求 €0.0001 充值预付额度，或选择每月 €50 的 Unlimited 密钥。每个端点和每个兼容替换主机的价格都相同。我们并不是通过一场旨在最大化单客户收入的定价优化得出这个方案的。我们是这样得出的：设想一位曾被不透明的档位、超额费用和企业销售电话困扰过的人，问问对他来说，这个具体产品公平、诚实的价格应该是什么样子，因为我们每个人都曾在某个时候是那个人。
同样的标准也适用于那些从不会出现在价格页面上的小决定：不额外收费地接受通过请求头、Bearer 令牌、Basic 认证或查询参数传递的密钥，因为强制使用某一种特定方式，对现有代码已经采用其他方式的人来说是不必要的阻碍。清楚地公开错误代码和速率限制，因为去猜测一个没有文档的失败，是在浪费所有人的时间。这些都不是惊天动地的决定。它们是在产品的每个部分一再坚持不做令人恼火之事的积累。
我们并不是说这让产品的每个部分都已完成或完美无缺。我们会明确说明哪些端点我们认为已完全可用，以及哪些端点（例如正向地理编码、逆地理编码和自动补全）我们会谨慎描述而不是夸大宣传，因为夸大宣传本身就是同一种失败的另一个版本：告诉客户他们想听的，而不是实际的真相。打造我们自己想购买的产品，意味着诚实地打造它，包括诚实地说明它目前的局限，而不只是打造那些容易让人引以为傲的部分。这是我们为自己设定的标准，也是我们打算一直接受检验的标准。