Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Développeurs de l'Espace économique européen (EEE)
L'API Route Optimization expose deux méthodes :
OptimizeTours est une méthode synchrone qui renvoie un itinéraire optimisé en réponse à un OptimizeToursRequest. Les clients doivent maintenir une connexion ouverte à l'API Route Optimization jusqu'à ce que la requête soit traitée et qu'une réponse OptimizeToursResponse ou une erreur soit renvoyée.
BatchOptimizeTours est une méthode asynchrone qui accepte les URI d'un ou de plusieurs OptimizeToursRequest et les messages OptimizeToursResponse correspondants. Elle renvoie le nom de ressource d'une opération de longue durée (LRO) (REST, gRPC) qui est utilisée pour vérifier l'état d'achèvement du lot. Les OptimizeToursRequest sont traités en arrière-plan. Les clients maintiennent donc une connexion ouverte à l'API Route Optimization uniquement le temps d'envoyer le BatchOptimizeToursRequest ou d'appeler GetOperation pour vérifier l'état de la LRO. BatchOptimizeTours lit les requêtes et écrit les réponses dans Google Cloud Storage.
Cas d'utilisation
OptimizeTours est pratique pour résoudre des requêtes simples et de petite taille, ou des requêtes dont le temps de résolution est de quelques minutes ou moins. Le maintien de connexions de longue durée à l'API Route Optimization augmente le risque d'interruption avant qu'une solution puisse être renvoyée.
BatchOptimizeTours peut traiter des requêtes plus volumineuses et des requêtes avec un temps de résolution plus long, car il ne nécessite pas de connexion de longue durée à l'API Route Optimization.
Opérations de longue durée
Les LRO sont lues à partir de l'API Route Optimization à l'aide de la méthode GetOperation pour vérifier l'état d'achèvement d'un lot. Les LRO incluent une propriété done qui indique si le traitement de l'ensemble du lot est terminé et un champ error qui signale les erreurs rencontrées lors du traitement. Si done est défini sur "true" et qu'aucun error n'est présent, cela signifie que le lot a été traité avec succès. La présence d'un error indique que le traitement d'une partie ou de l'intégralité du lot a échoué.
Le cycle de vie typique d'une requête BatchOptimizeTours est le suivant :
Envoyez un BatchOptimizeToursRequest à l'API Route Optimization, qui renvoie le nom de ressource d'une LRO.
Interrogez GetOperation avec le nom de ressource LRO renvoyé jusqu'à ce que les propriétés done ou error apparaissent dans la réponse LRO.
Si done est défini sur "true" et qu'aucune erreur n'est présente, lisez OptimizeToursResponses à partir des URI Google Cloud Storage spécifiés dans la requête BatchOptimizeTours. Si error est présent, inspectez l'erreur, mettez à jour les OptimizeToursRequest en conséquence dans Google Cloud Storage, puis réessayez si nécessaire en fonction de l'erreur observée.
Vous pouvez envoyer des requêtes OptimizeTours et BatchOptimizeTours de différentes manières, soit à partir de la ligne de commande, soit à l'aide d'une bibliothèque cliente.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/31 (UTC).
[null,null,["Dernière mise à jour le 2025/08/31 (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)"]]
