다음 권장사항은 Actions Center 예약 대기자 명단 통합에 적용되며 사용성 및 성능 문제를 방지하는 데 활용할 수 있습니다. 데이터 품질이 낮다면 인벤토리 게시 중단이 발생할 수 있습니다.
피드
- 서비스에 설정된 길이가 없으면 이용 가능 여부 피드의
duration_sec
를 다음 중 하나로 설정하세요.- 합리적인 방식으로 서비스를 수행하는 데 걸리는 시간(초)입니다.
-
서비스를 완료하는 데 필요한 평균 시간(초)입니다.
- 판매자 피드의
Category
필드를 구체적으로 입력합니다. 예를 들어 레스토랑은 프랑스어 또는 일본어와 같은 특정 유형을 제출할 수 있습니다. 자세한 내용은 장소 유형의 잠재적 카테고리 값을 참고하세요. -
판매자 피드의
Terms
필드에 판매자별 서비스 약관을 설정하여 도서 버튼 아래에 다음 메모가 표시되도록 합니다.계속 진행하면 <merchant>의 서비스 약관에 동의하는 것으로 간주됩니다.
이 경우 '서비스 약관'은 클릭하면 약관 텍스트 필드에 설정된 텍스트를 표시하는 링크입니다. -
gzip
을(를) 사용하여 피드를 압축합니다.
예약 서버
Maps Booking API 통합을 최적화하려면 다음 단계를 따르세요.
- 항상 UTC 형식으로 UNIX 타임스탬프를 사용합니다.
-
CreateBooking
API에서 새 예약이 호출될 때 고유한 예약 ID를 생성합니다.
실시간 업데이트
예약 과정에서 최상의 사용자 환경을 제공하려면 다음을 실행하세요.
- 표준 구현의 경우 BookingNotifications API를 사용하여 예약의 시작 시간, 기간, 예약 상태(예: 취소 또는 예약 불이행)를 변경합니다.
- 개발자 측에서 Actions Center 예약을 변경하면 항상 BookingNotification API를 사용하여 시스템에서 실시간 예약 업데이트를 실시간으로 전송하여 Actions Center 측에서 데이터가 오래된 상태가 되지 않도록 합니다. 예를 들어 Actions Center를 통해 시스템에서 예약을 취소, 변경, 업데이트할 수 있습니다.
UpdateBookingRequest
의 모든 예약 업데이트에 대해UpdateBookingResponse
값에 예약 ID가 포함되어 있고 업데이트된 모든 필드에 새 값이 반영되어야 합니다.-
인벤토리 RTU가 구현된 경우
- API 호출당 슬롯 100~1,000개의 배치로만 이용 가능 여부를 업데이트하세요.
-
*Restrict
(예:startTimeRestrict
) 필드를 사용하여 수정 대상의 범위를 좁히고 페이로드 크기를 줄이고 변경되지 않은 데이터를 너무 많이 다시 전송하지 않도록 하세요. -
여러 스레드를 스핀오프하는 경우 제한 오류를 방지하기 위해 지수 백오프를 구현합니다. 지수 백오프를 올바르게 구현하지 않으면
RESOURCE_EXHAUSTED
할당량 오류가 발생할 수 있습니다. 지수 백오프를 다시 시도하여 처리할 수 있지만ReplaceServiceAvailability
실행 시 서버가 할당량에 자주 도달하는 경우 가용성을 위해 일괄 교체하도록 서버를 구성하세요. 이 솔루션은 서비스가 실행해야 하는 API 호출 수를 줄이기 때문에 할당량 오류를 방지합니다.
- API 호출 응답 시간 제한을 1초 미만으로 설정합니다. 서버가 95% 이상의 시간 동안 1초 미만의 지연 시간으로 5개의 초당 쿼리 수 (QPS)를 처리할 수 있어야 합니다.