永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
授权数据有一个显而易见的吸引力:由单一供应商控制和整理,并且可以通过合同追究其质量责任。它也伴随着一种在首次签约时容易被低估的结构性风险:许可是与一方之间的关系,而这一方可以在未来续约时更改条款、提高价格或限制访问,而最初的协议从未对此提供充分保护。您的产品所依赖的数据集,可能会因为与数据本身毫无关系、完全取决于一场您未曾参与的谈判的原因,而变得更贵或更难获得。
开放的、由社区维护的参考数据并不能消除风险,但它改变了风险的形态,我们认为这种形态通常对建立在其上的产品更健康。IANA 时区数据库就是一个清晰的例子:它以开放方式维护,由与其准确性有直接利害关系的贡献者跟踪更新,任何人都可以在其基础上构建,数据与产品之间没有横亘着授权谈判。ISO 3166-1 下的国家代码和 ISO 3166-2 下的行政区划代码也是如此,它们是被广泛采用的参考标准,而不是由某一家公司控制访问权的东西。
在已有开放参考标准的地方基于这些标准构建,把专有投入留给产品中真正需要它的部分,例如地理编码本身背后的匹配逻辑和覆盖范围工作,让我们避免了从单一独家供应商获取时区规则或国家代码之类数据所带来的重新谈判风险。没有人能撤销我们对 IANA 数据库的访问权,也没有人能在下一次续约时把它的价格翻倍,因为在它与任何使用者之间并不存在独家合同。
这并不意味着开放数据的质量自然就高于授权数据,也不意味着授权总是错误的选择。有些数据确实需要持续的、有资金支持的、集中化的投入,而这只有商业供应商才能现实地提供;在没有质量相当的开放替代品时,为此付费是一种合理的取舍。我们的观点更为具体:在已经存在一个可靠且积极维护的开放标准的地方,基于同样的底层事实构建一个专有的授权替代品,大多只是重新制造了一开始就无需存在的供应商风险。
我们认为,在这种情况下,幕后的数据来源决策确实对客户很重要,尽管客户从未直接看到它们。一个在可行之处基于开放参考数据构建的产品,受单一供应商未来决策的影响更小,这意味着产品本身不太可能因为与客户所做的任何事情都无关的原因,而在客户脚下发生变化。