OptimizeTours는 OptimizeToursRequest에 대한 응답으로 최적화된 경로를 반환하는 동기식 메서드입니다. 클라이언트는 요청이 처리되고 OptimizeToursResponse 또는 오류가 반환될 때까지 Route Optimization API에 대한 열린 연결을 유지해야 합니다.
BatchOptimizeTours는 하나 이상의 OptimizeToursRequest 및 해당 OptimizeToursResponse 메시지의 URI를 허용하고 일괄 완료를 확인하는 데 사용되는 장기 실행 작업 (LRO)(REST, gRPC)의 리소스 이름을 반환하는 비동기 메서드입니다. OptimizeToursRequest는 백그라운드에서 처리되므로 클라이언트는 BatchOptimizeToursRequest를 제출하거나 GetOperation를 호출하여 LRO 상태를 확인할 만큼만 Route Optimization API에 대한 열린 연결을 유지합니다. BatchOptimizeTours는 Google Cloud Storage에서 요청을 읽고 응답을 씁니다.
사용 사례
OptimizeTours는 작고 간단한 요청을 해결하거나 해결 시간이 몇 분 이하인 요청에 적합합니다. Route Optimization API에 대한 장기 연결을 유지하면 솔루션을 반환하기 전에 중단될 위험이 증가합니다.
BatchOptimizeTours는 경로 최적화 API에 대한 장기 연결이 필요하지 않으므로 더 큰 요청과 해결 시간이 더 긴 요청을 처리할 수 있습니다.
장기 실행 작업
LRO는 GetOperation 메서드를 사용하여 Route Optimization API에서 읽어 일괄 처리의 완료 상태를 확인합니다. LRO에는 전체 일괄 처리의 완료 여부를 나타내는 done 속성과 처리 중에 발생한 오류를 보고하는 error 필드가 포함됩니다. done이 true이고 error이 없는 경우 일괄 처리가 성공적으로 완료된 것입니다. error이 있으면 배치 중 일부 또는 전체의 처리가 실패했음을 나타냅니다.
BatchOptimizeTours 요청의 일반적인 수명 주기는 다음과 같습니다.
LRO의 리소스 이름을 반환하는 경로 최적화 API에 BatchOptimizeToursRequest를 제출합니다.
done 또는 error 속성이 LRO 응답에 표시될 때까지 반환된 LRO 리소스 이름으로 GetOperation를 폴링합니다.
done이 true이고 오류가 없으면 BatchOptimizeTours 요청에 지정된 Google Cloud Storage URI에서 OptimizeToursResponses를 읽습니다. error가 있으면 오류를 검사하고 Google Cloud Storage에서 OptimizeToursRequest를 적절하게 업데이트한 후 관찰된 오류에 따라 적절하게 다시 시도합니다.
명령줄에서 또는 클라이언트 라이브러리를 사용하여 다양한 방법으로 OptimizeTours 및 BatchOptimizeTours 요청을 보낼 수 있습니다.
[null,null,["최종 업데이트: 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)"]]
