将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
在迁移过程中更新客户端库和 SDK
许多地理编码和位置数据集成根本不直接与 HTTP API 通信，而是通过官方客户端库或 SDK 进行，这些库或 SDK 会封装请求、处理身份验证，并以应用所用编程语言中的类型化对象返回结果。这一额外的层在日常使用中很方便，却给迁移带来了一个实际的麻烦，因为需要纳入计划的不只是背后的 API，还有这个库本身。
涉及客户端库的迁移大致有三种走向，在开始之前值得先确定适用哪一种：
库支持自定义基础 URL。有些官方客户端库的设计足够灵活，可以接受不同的请求基础 URL，同时保持其余接口不变。在这种情况下，如果响应结构与库期望解析的格式一致，把现有库指向一个兼容主机，基本上无需修改任何应用代码就能正常工作。这是最理想的情况，值得首先检查。
库与某个主机紧密耦合。许多客户端库把目标主机写死在代码中，或者对其服务商的身份验证流程做了特定假设，难以轻易重定向。在这种情况下，务实的做法通常是在迁移的调用中完全绕过该库，直接向新服务商的 API 发出请求，用您自己编写的轻量请求函数替代该库的类型化封装。
完全不涉及任何库。如果您的集成已经在不经过官方库的情况下直接发出原始 HTTP 请求，那么整个问题就不适用了，迁移只需更直接地更换主机、密钥，以及调整任何需要修改的响应解析。
由于 My Geocode 的身份验证支持 X-API-Key 请求头、Authorization: Bearer 请求头、HTTP Basic 认证或查询参数，一个已经采用其中任何一种常见方式进行身份验证的客户端库，即使没有针对本平台的官方第一方库支持，也很有可能只需更改基础 URL 并换上新密钥，就能与兼容主机配合使用。值得直接在预发布环境中进行测试，而不是想当然地认为它无需修改就能工作，或者认为它完全无法工作；实际结果完全取决于所涉及的具体库在编写时有多灵活。
无论适用哪种方式，都值得在迁移记录中明确记下这一决定，因为在迁移中被悄悄绕过却未加记录的库依赖，往往会让一年后维护代码的人感到困惑：他们更新了旧库，以为它仍在请求路径中。一条简短的注释，说明请求现在绕过了官方客户端库以及原因，就能在日后省去不少真正的困惑。