比較 OptimizeTours 和 BatchOptimizeTours

Route Optimization API 提供兩種方法:

  • OptimizeTours 是一種同步方法,可在 回應 OptimizeToursRequest。用戶端必須維持開放 會連線至 Route Optimization API,直到要求處理完成,並 傳回 OptimizeToursResponse 或錯誤。
  • BatchOptimizeTours 是一種非同步方法,可接受一個 URI 的 URI 或更多OptimizeToursRequest及相應的 OptimizeToursResponse 訊息,傳回 Long Running Operation (LRO) 的資源名稱 (RESTgRPC),用於檢查批次是否完成。 OptimizeToursRequest 會在背景處理,因此用戶端保持 與 Route Optimization API 之間的公開連線時間已足夠提交 BatchOptimizeToursRequest 或撥打 GetOperation 檢查 LRO 狀態 狀態。BatchOptimizeTours 會讀取來自 的要求,並將回應寫入 Google Cloud Storage

應用實例

OptimizeTours 相當方便 處理要求,所需時間不超過幾分鐘。維持長期運作 連至 Route Optimization API 的連線會增加 指出解決方案

BatchOptimizeTours 可以處理較大型的要求和要求,解決時間較長 則不需要長時間連線 最佳化 API。

長期執行的作業

LRO 會使用 GetOperation 方法從 Route Optimization API 讀取,以便 查看批次的完成狀態LRO 包含的 done 屬性: 會指出整個批次的處理程序是否已完成,且 error 欄位,回報處理期間發生錯誤。如果 done 為 true,且 沒有 error,表示批次已順利完成。存在 error 表示部分或所有批次處理作業失敗。

BatchOptimizeTours 要求的典型生命週期如下:

  1. BatchOptimizeToursRequest 提交至 Route Optimization API, 會傳回 LRO 的資源名稱。
  2. 使用傳回的 LRO 資源名稱輪詢 GetOperation,直到 doneerror 屬性會出現在 LRO 回應中。
  3. 如果 done 為 true 且沒有錯誤,請參閱 OptimizeToursResponsesBatchOptimizeTours 中指定的 Google Cloud Storage URI 請求。如果有 error,請檢查錯誤,然後更新 會在 Google Cloud Storage 中產生 OptimizeToursRequest,並以下列身分重試: 視觀察到的錯誤而定

您可以透過多種方式傳送 OptimizeToursBatchOptimizeTours 要求 透過指令列或使用用戶端程式庫

下一步:提出 API 要求