本月上线内容：地理编码、IP、时区等
API 近期工作汇总：新的兼容主机、更快的时区和海拔查询、控制台新功能，以及更清晰的配额可见性。
标签
#API
未验证密钥暂停前的宽限期
新账户的密钥在注册后的宽限期内继续有效，只有在该期限内始终未确认邮箱地址时才会暂停。
用于地址列表的新批量端点
地址列表现在可以通过一次批量调用发送，每个地址单独计数，而不是整个调用算作一次请求。
IP 威胁和网络详情可按需获取
在 IP 查询中添加 mg_extras=1 或 X-MG-Extras 请求头，现在会在标准响应之外额外返回可选的威胁和网络详情。
基础设施升级后响应速度更快
我们整个服务栈的基础设施升级降低了全平台的响应时间，任何请求或响应格式均无变化。
专用的邮政编码查询端点
邮政编码查询现在有了自己的专用端点，与通用地理编码分开，并有自己的文档和请求参数。
兼容替换主机新增自动补全建议
所有提供地址自动补全的兼容主机现在都支持地址自动补全请求，与各服务商自己的自动补全请求结构保持一致。
更快的海拔端点，适用于长路线
海拔端点现在能更高效地处理由大量坐标组成的长路线，面向请求海拔剖面图的路线规划和徒步应用。
公开的兼容性矩阵：十七个主机，一个密钥
现在有一个页面将全部十七个兼容主机并列展示，让您可以轻松看出哪些服务商能用一个密钥直接替换。
用通俗的语言解释速率限制
My Geocode 的速率限制比听起来简单：每个网络和每个密钥各有一份每日免费配额，超出后使用预付额度或 Unlimited 方案。
邮政编码覆盖范围扩展到更多国家
邮政编码查询的覆盖范围现在扩展到了比以往更多的国家，让邮政编码端点可以服务于更广泛的应用。
海拔数据已更新，山区准确性更高
/v1/elevation 背后的海拔数据已经更新，专门提高了在陡峭和山地地形中的准确性，而旧数据往往在这些地方表现不足。
重建查询表后，时区查询速度更快
每个请求背后的时区查询表已为提升速度而重建，请求结构和响应字段均无变化。
迁出 HERE autosuggest 集成
HERE 的 autosuggest 有自己独立于地理编码的请求模式。下面介绍在将其迁移到新服务商之前需要考虑清楚的事项。
迁出 Bing Maps 海拔集成
Bing 的海拔数据与其更广泛的 Maps 账户绑定在一起。下面介绍如何只提取并迁移这一项依赖。
迁出 Bing Maps 时区集成
Bing 的时区数据通常与其地理编码调用绑定在同一个账户下。下面介绍如何把这一部分分离出来并迁移。
每个响应都带有配额响应头：调用之前就知道您的限额
每个 My Geocode 响应都带有一整套配额响应头，因此脚本无需单独查询用量，就能准确知道自己的当前状态。
迁出 Google Places 自动补全集成
自动补全是较难迁移的部分之一，因为各服务商的请求模式和会话行为各不相同。下面介绍需要提前规划的内容。
迁出 Google Maps Platform 海拔集成
海拔查询通常只是大型 Google Maps 账户中的一项小依赖。下面介绍如何干净利落地迁移这一部分。
迁出 Google Maps Platform 时区集成
Google 时区查询通常与更大的 Maps Platform 账户捆绑在一起。下面介绍如何只迁移这一部分。
从 ipstack 迁移
ipstack 的嵌套 connection 对象和 access_key 参数是迁移时需要保留的常见模式。下面介绍具体做法。
从 ipinfo.io 迁移
ipinfo.io 简洁的 loc 和 org 字段影响了大量下游代码。下面介绍迁移到兼容替换主机时会保留哪些内容。
从 ip-api.com 迁移
ip-api.com 扁平的 JSON 响应在业内被广泛效仿。下面介绍迁移这一具体集成时会有哪些变化。
从 Open-Elevation 迁移
Open-Elevation 是一个自托管的开源海拔 API，请求结构简单。下面介绍迁移到托管端点会带来哪些变化。
所有端点均支持 IPv6
现在每个端点对待 IPv6 地址都与 IPv4 地址完全相同，从查询、配额计算到在同一网络中共享的免费配额，概莫能外。
正确解读置信度和精度字段
精度告诉您得到的是哪种匹配。置信度告诉您地理编码器有多确定。把两者混为一谈会导致错误的筛选逻辑。
无密钥访问：每天 2,500 次免费查询，无需注册
无需账户、无需银行卡、无需密钥即可开始。任何地址每天最多可免费发起 2,500 次地理编码、IP、时区和海拔请求。