为什么要迁移到 Routes API？

欧洲经济区 (EEA) 开发者

Routes API 在计算路线、距离和出行时间方面具有更高的性能，因此值得替换使用 Directions API 和 Distance Matrix API 的应用。Routes API 的大部分功能都向后兼容 Directions API 和 Distance Matrix API。

请参阅本指南，了解 Routes API 与其取代的产品之间的主要区别，以及如何处理必要的更改。如需详细了解其他 Routes API 功能，请参阅产品概览。

主要改进

本部分介绍了在应用中使用 Routes API 时可以期待的一些增强功能。

提高了请求限制

Routes API Compute Route Matrix
  • 最多 625 个元素，除非您指定 TRAFFIC_AWARE_OPTIMAL。
  • 最多可包含 100 个具有 TRAFFIC_AWARE_OPTIMAL 的元素。请参阅增强型路由偏好设置。
  • 最多可使用 50 个航点（出发地 + 目的地）（使用地点 ID）。
Distance Matrix API
  • 每个请求最多包含 25 个出发地或 25 个目的地。
  • 每个服务器端请求最多包含 100 个元素（出发地数量 × 目的地数量）。

更快获得请求响应

“计算路线矩阵”功能可实现以下延迟时间改进：

  • 在计算出整个矩阵之前，接收响应的流式传输元素。
  • 使用字段掩码自定义响应详情，仅请求所需的数据，这种最佳实践也有助于降低费用。
  • 改进了流量的路线计算，因此您可以在数据质量和响应时间之间做出权衡。

路由增强功能

计算路线功能提供以下路线规划增强功能：

  • 除了距离和预计到达时间之外，还提供过路费信息。
  • 双轮机动车路线。
  • 确定经停点的安全性。
  • 通过为途经点设置行驶方向和道路一侧，提高预计到达时间 (ETA) 的准确性。

仅请求您需要的数据

现在，您可以指定要返回的字段，从而缩短处理时间并减少账单费用。

Routes API
计算路线
计算路线矩阵		 您的请求必须使用字段掩码来指定您希望在响应中返回的字段。字段遮盖可确保您不会请求不必要的数据，这有助于避免产生不必要的处理时间和结算费用。
如需了解详情，请参阅选择要返回的字段。
Directions API
Distance Matrix API 		即使您的应用并非严格需要这些字段，也会返回默认字段列表。这可能会导致不必要的处理时间和结算费用。

增强了针对交通状况的路线计算功能

Routes API 支持三种路由偏好设置，您可以在请求流量信息时使用这些设置来平衡响应延迟时间和数据质量。

如需了解详情，请参阅配置质量与延迟时间。

TRAFFIC_UNAWARE
（默认）		 使用平均时间无关流量数据（而非实时流量数据）来计算路线，从而实现最低的响应延迟时间。此设置等同于在 Directions API 和 Distance Matrix API 中不使用路况信息。
TRAFFIC_AWARE
（新）		 优化了实时流量质量，以缩短延迟时间。与 TRAFFIC_AWARE_OPTIMAL 相比，此设置应用优化来大幅缩短延迟时间。 此设置也是 Routes API 的新设置，在 Directions API 或 Distance Matrix API 中没有对应的设置。
TRAFFIC_AWARE_OPTIMAL 高质量、全面的流量数据。此设置会产生最长的延迟时间，相当于 Directions API 和 Distance Matrix API 中的 departure_time 设置。
此偏好设置等同于 maps.google.com 和 Google 地图移动应用所使用的模式。

路线计算比较

下表比较了 Routes API 与 Directions API 和 Distance Matrix API 服务之间的路线规划选项。

流量选项 Routes API Directions API
Distance Matrix API		 延迟时间
无实时路况 TRAFFIC_UNAWARE 未设置 departure_time 属性 三种模式中延迟时间最短的模式。
已应用实时路况信息 TRAFFIC_AWARE 无对应报告

Routes API 新增的模式。与 TRAFFIC_UNAWARE 相比，该模型提供的延迟时间略长，但 ETA 质量略有下降。

它的延迟远低于 TRAFFIC_AWARE_OPTIMAL。
应用高质量、全面的实时路况数据 TRAFFIC_AWARE_OPTIMAL departure_time 属性集

相当于 maps.google.com 和 Google 地图移动应用使用的模式。

对于 Compute Route Matrix，请求中的元素数（出发地数量 × 目的地数量）不得超过 100。

主要差异

本部分介绍了 Routes API 与其取代的服务之间的主要区别，以及在现有应用中从这些服务迁移时，您可以采取哪些方法来解决这些差异。

改为调用一项服务，而不是两项

Routes API 在 API 控制台中，仅启用一项服务，以便您的应用使用 Compute Routes 和 Compute Route Matrix。
如需了解详情，请参阅在 Google API 控制台中进行设置。
Directions API
Distance Matrix API 		在 API 控制台中，将 Directions API 和 Distance Matrix API 作为单独的服务启用。

使用 HTTPS POST 请求

Routes API 在请求正文或标头中传递参数，作为 HTTP POST 请求的一部分。
如需查看示例，请参阅：
- 计算路线
- 计算路线矩阵
Directions API
Distance Matrix API 		使用 HTTP GET 请求传递网址参数。

ETA 回答差异

Routes API 会返回预计到达时间，并以不同于 Directions API 和 Distance Matrix API 服务的方式使用 duration 响应属性，如下表所示。

加大型文字广告的类型 Routes API Directions API
Distance Matrix API
不考虑路况，与时间无关的预计到达时间。

使用 TRAFFIC_UNAWARE 设置。

  • 包含在 duration 响应属性中的预计到达时间。
  • duration 和 staticDuration 响应属性包含相同的值。

对应于请求中未设置 departure_time。

  • 包含在 duration 响应属性中的预计到达时间。
  • 不返回 duration_in_traffic 响应属性。
考虑了实时路况信息的预计到达时间。

使用 TRAFFIC_AWARE 或 TRAFFIC_AWARE_OPTIMAL 进行设置。

  • 考虑了实时路况信息的预计到达时间包含在 duration 响应属性中。
  • staticDuration 响应属性包含在不考虑路况信息的情况下，沿路线行驶所需的时间。
  • 不再返回 duration_in_traffic 属性。

使用请求中的 departure_time 进行设置。

  • 考虑了实时路况信息的预计到达时间包含在 duration_in_traffic 响应属性中。

多段线航点

您不再需要使用此服务将纬度/经度坐标转换为折线航点，因为此服务支持 POST 请求正文，因此不再受网址字符串长度限制的影响。部分 Distance Matrix API 用户通过将纬度/经度点转换为折线航点，解决了请求限制问题。

设置了格式的地址（反向地理编码）

Routes API 不会在响应中提供格式化地址。如需获取格式化地址，请使用 Geocoding API，该 API 专为此用例而构建，可提供更高质量的结果。

可用的出行方式

与 Directions API 一样，如果路线请求未指定出行方式，Routes API 会将 DRIVE 用作默认模式。不过，如果请求确实为路线指定了出行方式，Routes API 不会返回可用出行方式的数组作为请求的替代选择。如果您的使用情形依赖于此功能，请提交问题，说明您如何使用此功能，以便我们跟进。

XML 作为响应格式

Routes API 不提供 XML 作为响应格式。您可以在网上找到许多 JSON 到 XML 的转换器，它们应该能满足您的需求。