永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
供应商锁定的隐性成本
没有人在注册一个 API 时就打算被它锁定。锁定并不是以一项您可以通过谈判去掉的合同条款的形式出现的。它是一点一点累积起来的，每次一个便利，直到切换的成本悄然超过了当初让您考虑切换的那个问题本身的成本。
它从小处开始。您安装了服务商的 SDK，因为它能省下几个小时手写 HTTP 调用的时间。您把响应对象的结构直接存入数据库，而不是映射到自己的数据模式，因为当时觉得这种映射是多余的工作。您围绕服务商特定的状态码构建错误处理，而不是采用通用模式。在正常的交付压力下，每一个选择在当时单独来看都合情合理。没有一个是出于锁定的考虑而做出的。但每一个都在加深锁定。
多年以后，服务商涨价了，或者在繁忙时段发生了故障，或者只是对于您现在需要的某项功能不再是最佳选择。切换本应只是选择一个新供应商并更新一个配置值的事情。实际上它却成了一个项目：重写分散在代码库各处的解析逻辑、重建错误处理、重新调整围绕旧结构发展起来的各种内部工具。切换成本从未出现在任何一张账单上。它早已被预先支付，体现在当时没有人标记为有风险的一个个小集成决策中。
我们构建兼容主机，正是为了应对这种模式。如果您的集成已经使用另一家服务商的请求和响应结构，把它指向我们的 17 个兼容主机之一，并不需要您事先为可移植性做过规划。您获得了离开的选择权，而无需当初就有为离开而构建的远见。这与大多数反锁定建议有着显著区别，那些建议往往会说“从第一天起就基于抽象层构建”，这是好建议，但在截止期限的压力下几乎没有人真正照做。
身份验证是同一原则的一个较小的例子。有些服务商会把您推向某一种特定的身份验证方式，把您的集成绑定到某种特定的客户端模式上。我们接受以 X-API-Key 请求头、Authorization Bearer 请求头、HTTP Basic 认证或查询参数的方式传递密钥，适用于每一个主机，且任何一种方式都不额外收费。无论您现有代码在其他 API 上已经使用什么模式，我们的服务很可能都适用，因此您不必仅仅为了试用我们而重写身份验证层。
锁定在这个行业中长期存在的真实原因是，它在商业上行之有效。一个仅因价格就会离开的客户，往往因为离开意味着重写代码而留了下来。我们认为这不是一个值得据以建立业务的好交易，因为它留住的是已经不满意的客户，而不是真正满意的客户。如果离开的成本始终很低，那么留下来的客户之所以留下，是因为产品仍然物有所值，而不是因为出口早在第二年的某个时候就被悄悄封死了。