Route Optimization API 公开了两种方法：
OptimizeTours是一种同步方法，用于返回针对OptimizeToursRequest的优化路线。客户端必须保持与路线优化 API 的连接处于打开状态，直到请求得到处理并返回OptimizeToursResponse或错误为止。BatchOptimizeTours是一种异步方法，可接受一个或多个OptimizeToursRequest的 URI 和相应的OptimizeToursResponse消息，并返回用于检查批处理完成情况的长时间运行的操作 (LRO) 的资源名称（REST、gRPC）。OptimizeToursRequest在后台处理，因此客户端只需保持与路线优化 API 的连接足够长的时间，以提交BatchOptimizeToursRequest或调用GetOperation来检查 LRO 状态。BatchOptimizeTours从 Google Cloud Storage 读取请求并将响应写入其中。
使用场景
OptimizeTours 非常适合解决小型简单请求，或解决时间不超过几分钟的请求。与路线优化 API 保持长期有效的连接会增加在返回解决方案之前中断的风险。
BatchOptimizeTours 可以处理更大的请求和求解时间更长的请求，因为它不需要与路线优化 API 建立长期连接。
长时间运行的操作
使用 GetOperation 方法从 Route Optimization API 读取 LRO，以检查批次的完成状态。LRO 包含一个 done 属性，用于指示整个批次的处理是否已完成；还包含一个 error 字段，用于报告处理期间遇到的错误。如果 done 为 true 且不存在 error，则表示批处理已成功完成。如果存在 error，则表示部分或全部批次处理失败。
BatchOptimizeTours 请求的典型生命周期如下：
- 向 Route Optimization API 提交
BatchOptimizeToursRequest，该 API 会返回 LRO 的资源名称。 - 使用返回的 LRO 资源名称轮询
GetOperation，直到 LRO 响应中出现done或error属性。 - 如果
done为 true 且不存在任何错误，则从BatchOptimizeTours请求中指定的 Google Cloud Storage URI 读取OptimizeToursResponses。如果存在error，请检查错误，在 Google Cloud Storage 中相应地更新OptimizeToursRequest，然后根据观察到的错误重试。
您可以通过多种方式发送 OptimizeTours 和 BatchOptimizeTours 请求，无论是通过命令行还是使用客户端库都可以。