Route Optimization API 公开了两种方法：
OptimizeTours是一种同步方法，用于响应OptimizeToursRequest返回优化的路线。在请求处理完毕并返回OptimizeToursResponse或错误之前，客户端必须保持与 Route Optimization API 的打开连接。BatchOptimizeTours是一种异步方法，用于接受一个或多个OptimizeToursRequest的 URI 和相应的OptimizeToursResponse消息，并返回用于检查批处理完成情况的长时间运行的操作 (LRO) 的资源名称 (REST、gRPC)。OptimizeToursRequest在后台处理，因此客户端与路线优化 API 之间的打开连接仅维持足够长的时间来提交BatchOptimizeToursRequest或调用GetOperation以检查 LRO 状态。BatchOptimizeTours从 Google Cloud Storage 读取请求并向其写入响应。
使用场景
OptimizeTours 便于解决小型简单请求，或者解决时间不超过几分钟的请求。与 Route Optimization API 保持长期有效的连接会增加在返回解决方案之前中断的风险。
BatchOptimizeTours 无需与路线优化 API 建立长时间连接，因此可以处理较大的请求和解决时间较长的请求。
长时间运行的操作
系统会使用 GetOperation 方法从路线优化 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 请求，包括通过命令行或使用客户端库。