永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么迁移应该只需一个下午，而不是一个季度
一个被规划为需要一个季度工程时间来更换位置数据服务商的迁移项目，通常并不是一个季度真正必要的工作。它是一个季度由多年前的设计决策制造出来的工作：必须逐字段拆解的专有响应格式，方法调用散落在代码库中无人记录之处的 SDK，围绕某家服务商特定状态码构建的错误处理。这些复杂性没有一项是查询地址或 IP 这件事本身所固有的。它们全都继承自那些让最初集成变得方便、却让未来迁移变得昂贵的选择。
我们构建 17 个兼容主机，正是为了让那一个季度变得没有必要，只要您现有的集成已经使用其中某家服务商的结构。如果您的代码调用某个知名地理编码或 IP API 的端点并解析其特定的响应格式，那么把同一段代码指向我们对应的兼容主机，应该只需更改基础 URL 和 API 密钥，而不需要重写多年来一直运行良好的解析逻辑。身份验证支持以请求头、Bearer 令牌、HTTP Basic 认证或查询参数的方式传递密钥，因此您现有代码采用的任何方式很可能都已得到支持。
只需一个下午的迁移，并不是我们轻易做出的承诺，因为我们非常清楚，为了让它成为现实，我们这边付出了多少努力：逐字段匹配另一家服务商的响应结构，用真实请求进行测试，并保持该结构稳定，让客户现有的代码除了请求发往何处之外，没有理由察觉到任何差别。这项工作被专门前置到我们身上，就是为了让它不必在下游、在每一个想测试切换是否值得的客户代码库中重新做一遍。
更广泛的观点不限于我们自己的兼容主机：一次需要一个季度的迁移，是关于之前那次集成的诊断信息，而不是更换服务商这件事的普遍固有属性。如果离开一家服务商需要一个历时数月的项目，那么总有某个人、在某个地方从这种阻碍的存在中获益，无论它是否是为此而刻意设计的。一家真正对自己的数据、价格和可靠性有信心的服务商，没有理由让客户难以离开，因为它全部的卖点应该是，试用过的客户不会想离开，而不是离开的代价太高、不值得尝试。
我们宁愿在产品是否值得留下这一点上竞争，并接受如实的评估，而且是在客户同样可以轻松离开的那个下午。让这个下午成为可能，花费了我们实实在在的工程投入。我们认为这是本应付出的投入，而任何不愿付出这种投入的服务商，都在悄悄地告诉您，它对自己所卖的东西究竟有多大信心。