Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Entwickler im Europäischen Wirtschaftsraum (EWR)
Die Route Optimization API bietet zwei Methoden:
OptimizeTours ist eine synchrone Methode, die als Reaktion auf eine OptimizeToursRequest eine optimierte Route zurückgibt. Clients müssen eine offene Verbindung zur Route Optimization API aufrechterhalten, bis die Anfrage verarbeitet und ein OptimizeToursResponse oder ein Fehler zurückgegeben wird.
BatchOptimizeTours ist eine asynchrone Methode, die URIs für einen oder mehrere OptimizeToursRequest und entsprechende OptimizeToursResponse-Nachrichten akzeptiert und den Ressourcennamen eines Vorgangs mit langer Ausführungszeit (LRO) (REST, gRPC) zurückgibt, der verwendet wird, um den Abschluss des Batches zu prüfen. OptimizeToursRequest werden im Hintergrund verarbeitet. Clients halten also nur so lange eine offene Verbindung zur Route Optimization API aufrecht, wie es für das Senden des BatchOptimizeToursRequest oder für den Aufruf von GetOperation zum Prüfen des LRO-Status erforderlich ist. BatchOptimizeTours liest Anfragen aus Google Cloud Storage und schreibt Antworten in Google Cloud Storage.
Anwendungsfälle
OptimizeTours eignet sich gut für kleine und einfache Anfragen oder für Anfragen, die in wenigen Minuten oder weniger beantwortet werden können. Wenn Sie dauerhafte Verbindungen zur Route Optimization API aufrechterhalten, steigt das Risiko von Unterbrechungen, bevor eine Lösung zurückgegeben werden kann.
BatchOptimizeTours kann größere Anfragen und Anfragen mit längerer Lösungszeit verarbeiten, da keine langlebige Verbindung zur Route Optimization API erforderlich ist.
Vorgänge mit langer Ausführungszeit
LROs werden über die Methode GetOperation aus der Route Optimization API gelesen, um den Abschlussstatus eines Batches zu prüfen. LROs enthalten das Attribut done, das angibt, ob die Verarbeitung des gesamten Batches abgeschlossen ist, und das Feld error, in dem Fehler gemeldet werden, die während der Verarbeitung aufgetreten sind. Wenn done „true“ ist und kein error vorhanden ist, wurde der Batch erfolgreich abgeschlossen. Das Vorhandensein eines error weist darauf hin, dass die Verarbeitung einiger oder aller Elemente des Batches fehlgeschlagen ist.
Der typische Lebenszyklus einer BatchOptimizeTours-Anfrage sieht so aus:
Senden Sie eine BatchOptimizeToursRequest an die Route Optimization API. Diese gibt den Ressourcennamen eines Vorgangs mit langer Ausführungszeit zurück.
Fragen Sie GetOperation mit dem zurückgegebenen LRO-Ressourcennamen ab, bis die Attribute done oder error in der LRO-Antwort angezeigt werden.
Wenn done „true“ ist und kein Fehler vorliegt, lesen Sie OptimizeToursResponses aus den in der BatchOptimizeTours-Anfrage angegebenen Google Cloud Storage-URIs. Wenn error vorhanden ist, prüfen Sie den Fehler, aktualisieren Sie die OptimizeToursRequest entsprechend in Google Cloud Storage und wiederholen Sie den Vorgang je nach beobachtetem Fehler.
Sie können OptimizeTours- und BatchOptimizeTours-Anfragen auf verschiedene Arten senden, entweder über die Befehlszeile oder mit einer Clientbibliothek.
[null,null,["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThe Route Optimization API offers two methods: \u003ccode\u003eOptimizeTours\u003c/code\u003e for synchronous processing of smaller, simpler requests and \u003ccode\u003eBatchOptimizeTours\u003c/code\u003e for asynchronous handling of larger, more complex requests.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eOptimizeTours\u003c/code\u003e requires an open connection until a response is received, while \u003ccode\u003eBatchOptimizeTours\u003c/code\u003e utilizes Google Cloud Storage for requests and responses, enabling background processing.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eBatchOptimizeTours\u003c/code\u003e relies on Long Running Operations (LROs) to track batch progress, which can be monitored via the \u003ccode\u003eGetOperation\u003c/code\u003e method.\u003c/p\u003e\n"],["\u003cp\u003eWhen using \u003ccode\u003eBatchOptimizeTours\u003c/code\u003e, users should submit the request, poll for completion using the LRO, and retrieve results or address errors as indicated by the LRO status.\u003c/p\u003e\n"]]],[],null,["# Synchronous and asynchronous endpoints\n\n**European Economic Area (EEA) developers** If your billing address is in the European Economic Area, effective on 8 July 2025, the [Google Maps Platform EEA Terms of Service](https://cloud.google.com/terms/maps-platform/eea) will apply to your use of the Services. Functionality varies by region. [Learn more](/maps/comms/eea/faq).\n\nThe Route Optimization API exposes two methods:\n\n- `OptimizeTours` is a *synchronous* method that returns an optimized route in response to an `OptimizeToursRequest`. Clients must maintain an open connection to the Route Optimization API until the request is processed and an `OptimizeToursResponse` or error is returned.\n- `BatchOptimizeTours` is an *asynchronous* method that accepts URIs for one or more `OptimizeToursRequest` and corresponding `OptimizeToursResponse` messages, returning the resource name of a *Long Running Operation* (LRO) ([REST](/maps/documentation/route-optimization/reference/rest/v1/projects.locations.operations#Operation), [gRPC](/maps/documentation/route-optimization/reference/rpc/google.longrunning#google.longrunning.Operations))) that is used to check for batch completion. `OptimizeToursRequest`s are processed in the background, so clients maintain an open connections to the Route Optimization API only long enough to submit the `BatchOptimizeToursRequest` or to call `GetOperation` to check LRO status. `BatchOptimizeTours` reads requests from and writes responses to [Google Cloud Storage](https://cloud.google.com/storage).\n\nUse cases\n---------\n\n`OptimizeTours` is convenient for solving small and simple requests, or for\nrequests with solving times of a few minutes or less. Maintaining long-lived\nconnections to the Route Optimization API increases risk of interruption before\na solution can be returned.\n\n`BatchOptimizeTours` can handle larger requests and requests with longer solving\ntime because it does not require a long-lived connection to the Route\nOptimization API.\n\nLong running operations\n-----------------------\n\nLROs are read from the Route Optimization API using the `GetOperation` method to\ncheck the completion status of a batch. LROs include a `done` property that\nindicates whether processing of the entire batch is complete and an `error`\nfield that reports errors encountered during processing. If `done` is true and\nno `error` is present, the batch completed successfully. The presence of an\n`error` indicates that some or all of the batch failed processing.\n| **Note:** REST `GetOperation` responses omit the `done` property if its value is false and the `error` property if no errors occurred.\n\nThe typical lifecycle of a `BatchOptimizeTours` request is as follows:\n\n1. Submit a `BatchOptimizeToursRequest` to the Route Optimization API, which returns the resource name of an LRO.\n2. Poll `GetOperation` with the returned LRO resource name until the `done` or `error` properties appear in the LRO response.\n3. If `done` is true and no error is present, read `OptimizeToursResponses` from the Google Cloud Storage URIs specified in the `BatchOptimizeTours` request. If `error` is present, inspect the error, update the `OptimizeToursRequest`s accordingly in Google Cloud Storage, and retry as appropriate depending on the observed error.\n\nYou can send `OptimizeTours` and `BatchOptimizeTours` requests in a variety of\nways, either from the command line or using a client library.\n\n[Next: Make an API Request](/maps/documentation/route-optimization/make-request)"]]
