永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么兼容主机比新的 SDK 更重要
每家 API 公司都希望您安装它的 SDK。SDK 具有黏性。一旦您的代码库导入了某个客户端库、调用它的方法并依赖它的对象结构，更换服务商就意味着要重写与服务商通信的代码，而不只是更改一个 URL。这种黏性往往才是免费又方便的 SDK 背后真正的商业模式，无论是否有人公开说出来。
我们采取了不同的做法。My Geocode 有 17 个兼容主机，每一个都复现了另一家服务商自己的请求和响应结构。如果您的代码已经知道如何调用某个知名地理编码 API 的端点并解析它的 JSON，您可以把这段代码原封不动地指向我们的兼容主机，它会继续正常工作。无需安装 SDK，无需重写响应解析，也无需学习专有的对象模型。
这听起来是件小事，直到您真正尝试把一个生产系统从某个 API 上迁移出来。端点 URL 是容易的部分。困难的部分是代码库中每一处读取特定字段名、处理特定错误结构或假定特定分页方式的地方。这些假定经年累月散落在代码库中，藏在没人记得去检查的地方。兼容主机免去了寻找和修复它们的需要，因为结构不会改变。
相比之下，SDK 解决的是一个您只会遇到一次的问题，即第一次连接 API，代价却是一个您在产品整个生命周期内都要面对的问题：被绑定在该 SDK 的设计决策上。当 SDK 发布破坏性变更时，您得承受。当它停止维护您所依赖的某个语言绑定时，您也得承受。一个纯 HTTP 兼容主机完全没有这些问题面。它只是一个 URL，返回您早已知道如何读取的响应结构。
我们并不是一概反对 SDK。一个帮您省去编写 HTTP 样板代码的轻量封装是一种便利，而不是陷阱，只要日后弃用它不会变成一个和更换服务商一样大的项目。陷阱在于 SDK 的结构成了您的代码唯一能理解的结构，于是离开就意味着重写，而不是重新配置。
构建 17 个兼容主机，对我们来说比构建一个 SDK 的工作量更大。每个主机都必须逐字段地紧密匹配另一家服务商的响应结构，让现有集成察觉不到任何差别。我们之所以做这项工作，是因为它把切换成本从您那边转移到了我们这边。您可以测试我们的数据、正常运行时间和价格是否适合您，而不必为了弄清楚这一点先付出集成成本。请查看兼容主机完整列表或文档，了解每个主机如何与原服务对应。
一个新 SDK 要求开发者在项目的整个生命周期内信任一家公司的工程选择。兼容主机的要求则少得多：更改一个基础 URL，也许再换一个 API 密钥，然后看看结果如何。这是一笔更公平的交易，也是我们先于其他一切构建兼容主机的原因。