Apple Maps Server API 简介

♪ ♪ ♪ 大家好！ 我叫 Ankur Soni 我是 Apple 地图服务团队的 工程经理 今天 我们要看一下即将进入 地图开发者生态系统的 一些令人兴奋的新功能 让我们现在开始吧 我们的“地图”App 可以为全球 Apple 用户 提供多样的终端用户体验 我们授权开发者 通过 MapKit 和 MapKit JS 去搭建属于他们的 体验优秀的 地理定位 App 和网站 并且 我们的 Apple 地图开发者服务 一直坚持以用户为中心 我们会悉心聆听所有反馈和建议 您会希望在不影响性能 或增加功耗的前提下 在 MapKit 上扩充您的数据 因此 为了完善我们的生态系统 我现在很高兴向您介绍 Apple Maps Server API 我们正在增加 四个新的 Server API 分别是 Geocode (地理编码) Reverse Geocoding (反向地理编码) Search (搜索) 以及 ETA (预计到达时间) 在把地图合并 导入到您的 App 中时 这些 API 将帮助您处理各种用例 使用 Geocode API 您可以将地址 转换为地理坐标 纬度和经度 同理 使用 Reverse Geocoding API 您可以通过一个逆向的过程 得到从地理坐标到地址的信息 借助 Search API 您可以为用户提供 输入企业名称 兴趣点等关键词 查找地点的功能 也许您想覆盖一些您自己的数据 并将其呈现给用户 通过 ETA API 您可以帮助您的用户 了解您的业务离他们有多远 或进行一些计算以找到最近的商店 可能性是无限的！ 您很可能会因为三个重要原因 而喜欢上我们的 Server API 首先 您现在可以 体验到 MapKit、MapKit JS 和全新的 Apple Maps Server API 实现功能上的无缝衔接 这在简化您的 App 架构的同时 还能为您提供 更多的 Apple Maps 堆栈 这将使您的生活更轻松 当然 它也帮助了我 但是 嘿 可能我 对它有偏爱滤镜 其次 我们的 Server API 可以减少网络调用 很多时候 我们经常 会陷入这样一种情况 我们在诸如 iPad、iPhone 和网站等 用户设备上不断地提出 重复和冗余的请求 也许您也曾经试过 在不同的设备的同一个 App 上 一遍又一遍地查找同一个地址 这大大增加了网络调用 造成带宽浪费 但如果将此常见操作 委托给您的服务器 并且只在后端 使用 Server API 执行一次 那么就能实现 减少 App 带宽消耗的目的 并且 通过委托 使用 Apple Maps Server API 实现您的 App 的一些功能 就能进一步减少 您 App 的功耗了 现在让我们来看看 其中一些 API 的接口吧 假设我们正在为您的定位 App 创建地图名片 这里我们看到三个商店及其地址 以及与用户位置的距离 在本例中 我们假设用户 提供了他们的位置 现在 让我们开始着手 创建其中一张地图名片 我们假设 包括这家漫画书店在内的地址信息 已经储存在服务器上 并且可以随时进行调用 我们现在有很多方法 可以创建 但等一下 假设我们现在 没有这些新的 Server API 那么 App 的基本架构 会是什么样子？ 您的 App 将如何获取这些数据？ 在此图中 我们的 App 先向服务器发送请求 以获取漫画书店地址列表 后端服务器返回漫画书店地址列表 到您的客户端设备 由于我们在此示例中 没有新的 Server API 所以我们的 App 在创建一张地图名片 就必须执行大量操作 每执行一次任务 用户可能都需要多次 向后端服务器发送请求 在这里您可以看到客户端正在 直接向 Apple Maps Server 发送请求 或者通过 MapKit 或 MapKit JS 客户端和后端服务器之间的这种互动 会对 App 的性能和大小 产生负面影响 在通常具有高延迟的蜂窝网络上 以这种方式使用单个请求 效率很低 甚至可能导致连接中断 或数据丢失 当每个请求可以并行完成时 App 必须 在单独的连接上发送 等待 和处理每个请求的数据 而这将增加失败的可能 最后 您将必须 合并客户端上的所有响应 当所有这些调用发生时 您正在向用户展示一个微调器 另外 客户端设备 需要为这些额外的调用 使用更多的带宽和功耗 这样的用户体验并不好 现在 让我们来看一下使用了 Apple Maps Server API 的模型架构 您可以开始使用后端服务器作为网关 以减少客户端和服务器之间的互动 和以前一样 这里我们从您的客户端 向后端服务器发送一个 显示漫画店列表的请求 接下来 我们 从服务器发出请求以进行地理编码 然后我们会收到 来自 Apple Maps Server 的 每个 API 的响应 漫画书服务器组合 来自每个服务的响应 并将响应发送给 App 此模式可以减少 App 对后端服务的请求数量 并在高延迟网络上 提高 App 的性能 总而言之 您的客户端仅向您的服务器 发送了一次获取存储列表的请求 然后您的服务器完成繁重的工作 进行了相应的 API 调用并组成 最符合用户需求的响应呈现给用户 所以 让我们回到 这里的案例研究示例 我们将使用地理编码 和 ETA API 来获取到商店的距离 我们可以使用地理编码 API 来查找纬度和经度 我们稍后将使用商店地址 用于预计到达时间计算 在这个例子中 首先 我们将采取 漫画书店的地址 和 URL 对其进行编码 接下来 我们将使用 Geocode API 并将这个 URL 编码的地址 作为查询参数传递 我们现在暂时跳过认证的细节 在几张幻灯片中再来讨论它 在响应中 可以看到 返回的地址的经纬度 我们将重复相同的流程来找到 客户地址的经纬度 这将在稍后用于预计到达时间计算 如您所见 响应中有更多字段 我会在下方的资源部分 链接详细的文档 现在 我们可以 用从 Geocode API 获得的数据 在 ETA API 上 设置起点和终点 正如我之前提到的 我们有起点纬度 经度 以及目的地的纬度 经度 如果需要 我们最多可以 在此处指定 10 个目的地 我们以 URL 编码的格式 把起点信息和终点信息 提供给 ETA API 我们可以通过 API 输出每个目的地 的预计到达时间列表 在这个案例中 因为我们只提供了一个目的地 所以我们只有 一个预计到达时间反馈信息 这是我们的示例 假设我们 想使用 distanceMeters 计算到商店的距离 有了这些 我们就有了所需的 所有信息：商店地址和 用户与商店的距离 您还可以选择使用个性化的商店信息 扩充或修改此数据 如商店营业时间 通过这种方式 您可以利用不同的 Server API 构建您的 App 其他 API 请参考 在本视频下方的文档链接 我们尚未讨论的 一个关键部分是身份验证 所有 Apple Maps Server API 都经过了身份验证 如果您使用的是 MapKit JS 那么您已经完成了一半 Apple Maps Server API 使用与 MapKit JS 相同的机制 进行身份验证 首先 您将从您的开发者帐户 下载您的私钥 然后 您将使用此私钥 生成 JWT 格式的地图身份 验证令牌 下方链接有如何生成 该令牌的详细文档 然后 您可以 使用令牌 API 交换这个 地图认证令牌来获得地图访问令牌 我们将在后端验证地图身份验证令牌 并发回地图访问令牌 这是 JWT 格式 将用于所有 API 交互 此访问令牌需要通过重复此处 突出显示的过程 每 30 分钟刷新一次 现在我们看到了 身份验证流程是什么样的 这是一个如何使用令牌 API 来获取访问令牌的简单示例 我们在这里使用的是令牌 API 我们将地图认证令牌 作为头文件传递 您将收到一个地图访问令牌 可用于访问 API 它将采用 JWT 格式 并具有标准字段 如 expiry、issuedAt 等 为方便起见 expiresInSeconds 字段 显示令牌的有效时间 在这种情况下 有效时间是 30 分钟 请记住地图身份验证令牌 与地图访问令牌不同 您交换地图认证令牌 以获得一个 时效为 30 分钟的地图访问令牌 来访问 Server API 让我们快速看看有地图访问令牌的 API 交互是怎么样的 我们将通过 Server API 调用 传递地图访问令牌 它作为头文件 添加到 API 调用中 就像我们之前 看到的几张幻灯片一样 Apple Maps Server 将验证地图访问令牌 验证成功后 Apple Maps Server 将会响应 API 的请求 现在我已经 介绍了 API 和身份验证 让我谈谈使用限制 能力越大 责任越大 所以请明智地使用您的配额 每天可以进行的 API 调用 是有上限的 但这个上限值很高 每天您总共将获得 25,000 个请求配额 请记住 通过 MapKit JS 和 Server API 调用服务都使用相同的配额 如果您需要更多配额 请与我们联系 那么 您如何跟踪这一切呢？ 您可以在地图开发者主页中 查看使用情况 有人正在使用 MapKit JS 吗？ 这对您来说会很熟悉 Server API 的使用 被归类为服务 您可以在此处突出显示 当超过每日配额时 也就是超过 25,000 个 Server API 调用 我们将开始拒绝新的服务调用 并以 HTTP 429 状态响应 这表示有太多的请求 在这种情况下 您应该确保 App 产生的数据 可以被有效地压缩 在极少数情况下 当您的服务 发出不寻常的请求量时 可能是由于代码 或基础结构中的一些 Bug 也可能是 得到 HTTP 429 状态 当您接收 HTTP 429 状态时 请尽量避免 再重复机械地继续发送请求 更好的方法是 稍后再进行重试 这种方法称为指数避退 那么 我们今天了解到了什么？ 我们发布了 四个新的 Server API 这些 API 分别是 Geocode、Reverse Geocoding Search 和 ETA 将这些 API 与 MapKit 和 MapKit JS 结合使用 将帮助您更好地 使用 Apple Maps 堆栈 构建您的 App 您可以通过 使用 Apple Maps Server API 将这些任务委派给您的后端服务器 以此优化冗余 减少重复调用 这些 API 的每日配额 为 25,000 次 并与您的 MapKit JS 服务 使用共享 这就是为您而设的 全新 Apple Maps Server API 请务必观看我们提及的 关联讲座 以及下面链接的详细文档 我们期待看到您 充分利用这些 API 感谢收看！ ♪