Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Desarrolladores del Espacio Económico Europeo (EEE)
La API de Route Optimization expone dos métodos:
OptimizeTours es un método síncrono que devuelve una ruta optimizada en respuesta a un OptimizeToursRequest. Los clientes deben mantener una conexión abierta a la API de Route Optimization hasta que se procese la solicitud y se devuelva un OptimizeToursResponse o un error.
BatchOptimizeTours es un método asíncrono que acepta URIs para uno o más mensajes de OptimizeToursRequest y OptimizeToursResponse correspondientes, y muestra el nombre del recurso de una operación de larga duración (LRO) (REST, gRPC) que se usa para verificar la finalización del lote. Los OptimizeToursRequest se procesan en segundo plano, por lo que los clientes mantienen conexiones abiertas con la API de Route Optimization solo el tiempo suficiente para enviar el BatchOptimizeToursRequest o llamar a GetOperation para verificar el estado de la LRO. BatchOptimizeTours lee solicitudes de Google Cloud Storage y escribe respuestas en él.
Casos de uso
OptimizeTours es conveniente para resolver solicitudes pequeñas y simples, o solicitudes con tiempos de resolución de unos minutos o menos. Mantener conexiones de larga duración con la API de Route Optimization aumenta el riesgo de interrupción antes de que se pueda devolver una solución.
BatchOptimizeTours puede controlar solicitudes más grandes y solicitudes con un tiempo de resolución más largo porque no requiere una conexión de larga duración a la API de Route Optimization.
Operaciones de larga duración
Los LRO se leen desde la API de Route Optimization con el método GetOperation para verificar el estado de finalización de un lote. Los LRO incluyen una propiedad done que indica si se completó el procesamiento de todo el lote y un campo error que informa los errores que se encontraron durante el procesamiento. Si done es verdadero y no hay ningún error presente, el lote se completó correctamente. La presencia de un error indica que falló el procesamiento de parte o de todo el lote.
El ciclo de vida típico de una solicitud de BatchOptimizeTours es el siguiente:
Envía un BatchOptimizeToursRequest a la API de Route Optimization, que devuelve el nombre del recurso de una LRO.
Sondea GetOperation con el nombre del recurso de la LRO que se devolvió hasta que aparezcan las propiedades done o error en la respuesta de la LRO.
Si done es verdadero y no hay ningún error, lee OptimizeToursResponses de los URIs de Google Cloud Storage especificados en la solicitud BatchOptimizeTours. Si error está presente, inspecciona el error, actualiza los OptimizeToursRequests según corresponda en Google Cloud Storage y vuelve a intentarlo según sea necesario en función del error observado.
Puedes enviar solicitudes de OptimizeTours y BatchOptimizeTours de diversas maneras, ya sea desde la línea de comandos o con una biblioteca cliente.
[null,null,["Última actualización: 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)"]]
