Лучшие практики

Следующие рекомендации применимы к интеграции списков ожидания резервирования Actions Center и могут быть использованы, чтобы избежать проблем с удобством использования и производительностью. Низкое качество данных может привести к удалению инвентаря.

Ленты

  • Если для услуги не задана длина, задайте для параметра duration_sec в канале доступности одно из следующих значений:
    • Количество секунд, необходимое для разумного выполнения услуги.

    • Среднее количество секунд, необходимое для завершения услуги.

  • Сделайте поле Category в фиде продавца конкретным. Например, ресторан может указать определенный тип, например французский или японский. Подробную информацию см. в разделе «Типы мест для потенциальных значений категорий».

  • Задайте условия обслуживания для конкретных продавцов в поле Terms фида продавцов, чтобы под кнопкой «Забронировать» появилось следующее примечание:

    Продолжая, вы соглашаетесь с Условиями обслуживания <merchant> .
    В данном случае «Условия обслуживания» — это ссылка, при нажатии на которую отображается текст, установленный в текстовом поле условий .

  • Сжимайте каналы с помощью gzip

Сервер бронирования

Чтобы оптимизировать интеграцию Maps Booking API, выполните следующие действия:

  • Всегда используйте временные метки UNIX в формате UTC.
  • Создавайте уникальный идентификатор бронирования при вызове нового бронирования в API CreateBooking .

Обновления в реальном времени

Чтобы обеспечить максимальное удобство взаимодействия с пользователем во время процесса бронирования, выполните следующие действия:

  • В стандартной реализации используйте API BookingNotifications, чтобы изменить время начала, продолжительность и состояние бронирования, например отмену или неявку встречи.
  • При любых изменениях в бронировании в Центре действий с вашей стороны всегда отправляйте обновления бронирования в режиме реального времени из системы с помощью API BookingNotification в режиме реального времени, чтобы данные не устаревали на стороне Центра действий. Например, вы можете отменить, перенести или обновить бронирование из своей системы в Центре действий.
  • Для каждого обновления бронирования из UpdateBookingRequest убедитесь, что значение UpdateBookingResponse содержит идентификатор бронирования и что все обновленные поля должны отражать новое значение.
  • Если Inventory RTU реализован
    • Обновляйте доступность только партиями по 100–1000 слотов на вызов API.
    • Используйте поля *Restrict (например, startTimeRestrict ), чтобы сузить область редактирования, уменьшить размер полезных данных и избежать повторной отправки слишком большого количества неизмененных данных.
    • Если вы выделяете несколько потоков, реализуйте экспоненциальную отсрочку , чтобы предотвратить ошибки регулирования. Если вы неправильно реализуете экспоненциальную отсрочку, вы можете получить ошибку квоты RESOURCE_EXHAUSTED . Вы можете повторить экспоненциальную отсрочку, чтобы справиться с ними, но если вы обнаружите, что ваш сервер часто достигает квот при запуске ReplaceServiceAvailability , настройте свой сервер на пакетную замену для обеспечения доступности . Это решение предотвращает ошибки квоты, поскольку уменьшает количество вызовов API, которые должен выполнить ваш сервис.
  • Установите ограничение времени ответа на вызов API менее одной секунды. Убедитесь, что ваш сервер может обрабатывать пять запросов в секунду (QPS) с задержкой менее секунды как минимум в 95 % случаев.