同步和异步端点

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 请求的典型生命周期如下所示：

1. 向 Route Optimization API 提交 BatchOptimizeToursRequest，该 API 会返回 LRO 的资源名称。
2. 使用返回的 LRO 资源名称轮询 GetOperation，直到 LRO 响应中显示 done 或 error 属性。
3. 如果 done 为 true 且没有错误，则从 BatchOptimizeTours 请求中指定的 Google Cloud Storage URI 读取 OptimizeToursResponses。如果存在 error，请检查错误，在 Google Cloud Storage 中相应地更新 OptimizeToursRequest，并根据观察到的错误酌情重试。

您可以通过多种方式发送 OptimizeTours 和 BatchOptimizeTours 请求，包括通过命令行或使用客户端库。

下一步：发出 API 请求