Route Optimization API 公開了兩種方法：
OptimizeTours是同步方法，會傳回回應OptimizeToursRequest的最佳化路線。在要求處理完畢並傳回OptimizeToursResponse或錯誤之前，用戶端必須維持與 Route Optimization API 的連線。BatchOptimizeTours是非同步方法，可接受一或多個OptimizeToursRequest的 URI 和對應的OptimizeToursResponse訊息，並傳回「長時間執行的作業」(LRO) 的資源名稱 (REST、gRPC)，用於檢查批次完成情況。OptimizeToursRequest會在背景處理，因此用戶端只需維持與 Route Optimization API 的連線，提交BatchOptimizeToursRequest或呼叫GetOperation檢查 LRO 狀態即可。BatchOptimizeTours會讀取要求，並將回應寫入 Google Cloud Storage。
用途
OptimizeTours 適合解決簡單的小問題，或解決時間不超過幾分鐘的要求。如果與 Route Optimization API 維持長時間連線，在系統傳回解決方案前，連線中斷的風險會增加。
BatchOptimizeTours 可處理較大的要求和解決時間較長的要求，因為不需要與 Route Optimization API 建立長期連線。
長時間執行的作業
使用 GetOperation 方法從 Route Optimization API 讀取 LRO，即可檢查批次作業的完成狀態。LRO 包含 done 屬性，可指出整個批次是否已處理完畢，以及 error 欄位，可回報處理期間發生的錯誤。如果 done 為 true 且沒有 error，表示批次作業已順利完成。如果出現 error，表示部分或所有批次處理作業失敗。
BatchOptimizeTours 要求的典型生命週期如下：
- 向 Route Optimization API 提交
BatchOptimizeToursRequest，這會傳回 LRO 的資源名稱。 - 使用傳回的 LRO 資源名稱輪詢
GetOperation，直到 LRO 回應中出現done或error屬性為止。 - 如果
done為 true 且沒有錯誤，請從要求中指定的BatchOptimizeToursGoogle Cloud Storage URI 讀取OptimizeToursResponses。如果出現error，請檢查錯誤，在 Google Cloud Storage 中相應更新OptimizeToursRequest，然後視觀察到的錯誤適當重試。
您可以透過多種方式傳送 OptimizeTours 和 BatchOptimizeTours 要求，包括使用指令列或用戶端程式庫。