Punkty końcowe synchroniczne i asynchroniczne

Deweloperzy z Europejskiego Obszaru Gospodarczego (EOG)

Interfejs Route Optimization API udostępnia 2 metody:

  • OptimizeTours to metoda synchroniczna, która zwraca zoptymalizowaną trasę w odpowiedzi na OptimizeToursRequest. Klienci muszą utrzymywać otwarte połączenie z interfejsem Route Optimization API, dopóki żądanie nie zostanie przetworzone i nie zostanie zwrócona wartość OptimizeToursResponse lub błąd.
  • BatchOptimizeTours to metoda asynchroniczna, która akceptuje identyfikatory URI co najmniej 1 OptimizeToursRequest i odpowiadające im komunikaty OptimizeToursResponse. Zwraca nazwę zasobu długo trwającej operacji (LRO) (REST, gRPC), która służy do sprawdzania, czy przetwarzanie wsadowe zostało zakończone. OptimizeToursRequest są przetwarzane w tle, więc klienci utrzymują otwarte połączenia z interfejsem Route Optimization API tylko na czas przesyłania BatchOptimizeToursRequest lub wywoływania GetOperation w celu sprawdzenia stanu LRO. BatchOptimizeTours odczytuje żądania i zapisuje odpowiedzi w Google Cloud Storage.

Przypadki użycia

OptimizeTours jest wygodny w przypadku rozwiązywania małych i prostych problemów lub żądań, których rozwiązanie zajmuje kilka minut lub mniej. Utrzymywanie długotrwałych połączeń z interfejsem Route Optimization API zwiększa ryzyko przerwania połączenia, zanim zostanie zwrócone rozwiązanie.

BatchOptimizeTours może obsługiwać większe żądania i żądania wymagające dłuższego czasu rozwiązywania, ponieważ nie wymaga długotrwałego połączenia z interfejsem Route Optimization API.

Długo trwające operacje

Długotrwałe operacje są odczytywane z interfejsu Route Optimization API za pomocą metody GetOperation, aby sprawdzić stan ukończenia partii. Obiekty LRO zawierają właściwość done, która wskazuje, czy przetwarzanie całego pakietu zostało zakończone, oraz pole error, które zgłasza błędy napotkane podczas przetwarzania. Jeśli wartość done to „true” i nie ma error, oznacza to, że partia została przetworzona. Obecność znakuerror oznacza, że przetwarzanie niektórych lub wszystkich elementów w partii nie powiodło się.

Typowy cykl życia żądania BatchOptimizeTours wygląda tak:

  1. Prześlij BatchOptimizeToursRequest do interfejsu Route Optimization API, który zwraca nazwę zasobu LRO.
  2. Wyślij zapytanie do interfejsu GetOperation z zwróconą nazwą zasobu LRO, dopóki w odpowiedzi LRO nie pojawią się właściwości done lub error.
  3. Jeśli done ma wartość true i nie występuje żaden błąd, odczytaj OptimizeToursResponses z adresów URI Google Cloud Storage podanych w żądaniu BatchOptimizeTours. Jeśli występuje znak error, sprawdź błąd, odpowiednio zaktualizuj elementy OptimizeToursRequest w Google Cloud Storage i spróbuj ponownie, w zależności od zaobserwowanego błędu.

Żądania OptimizeTours i BatchOptimizeTours możesz wysyłać na różne sposoby, zarówno z wiersza poleceń, jak i za pomocą biblioteki klienta.

Dalej: tworzenie żądania do interfejsu API