Шаг 3. Внедрите сервер бронирования списков ожидания.

Вам необходимо настроить сервер бронирования, чтобы Центр действий мог выполнять обратные вызовы для создания и обновления бронирований от вашего имени.

• Реализация списков ожидания резервирования. Это используется, когда вы участвуете в пилотной программе списков ожидания резервирования. Это позволяет Центру действий получать оценки ожидания и создавать записи в списке ожидания от имени пользователя.
• Стандартная реализация. Это позволяет Центру действий создавать встречи, заказы и резервирования у вас от имени пользователя. Чтобы реализовать сервер бронирования для сквозной интеграции Reservations, ознакомьтесь с разделом «Реализация сервера бронирования» .

Обратитесь к документации партнерского портала , чтобы узнать, как настроить подключение к песочнице и производственным серверам бронирования.

Реализуйте интерфейс REST API.

Внедрите интерфейс API на основе REST. Это позволяет Google отправлять запросы к серверу бронирования через HTTP.

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

Методы

Для каждого типа сервера бронирования с вашей стороны требуется свой набор методов API. При желании вы можете скачать определение сервиса в формате прототипа, чтобы начать реализацию API. В следующих таблицах показаны методы для каждой реализации и приведены ссылки на форматы прототипов служб.

API-ресурсы

Список ожидания

Для реализации бронирования на основе списка ожидания используются следующие ресурсы:

• WaitEstimate : оценка ожидания для определенного размера группы и продавца.
• WaitlistEntry : запись пользователя в списке ожидания.

Поток: создать запись в списке ожидания

В этом разделе описано, как создать бронирование для интеграции списков ожидания резервирования.

Когда пользователь создает запись в списке ожидания, Google отправляет вам имя, фамилию, номер телефона и адрес электронной почты пользователя. Электронная почта совпадает с учетной записью Google пользователя и рассматривается как уникальный идентификатор. С вашей точки зрения, этот список ожидания следует рассматривать как гостевую оплату, поскольку функция «Забронировать через Google» не может найти учетную запись пользователя в вашей системе. Убедитесь, что окончательная запись в списке ожидания идентична записям ваших продавцов, поступающим из вашей системы списков ожидания.

Безопасность и аутентификация

Вся связь с вашим сервером бронирования происходит через HTTPS, поэтому очень важно, чтобы ваш сервер имел действительный сертификат TLS, соответствующий его DNS-имени. Чтобы помочь в настройке вашего сервера, мы рекомендуем использовать бесплатно доступный инструмент проверки SSL/TLS, например Qualys's SSL Server Test .

Все запросы Google к вашему серверу бронирования будут аутентифицированы с использованием базовой аутентификации HTTP. Базовые учетные данные аутентификации (имя пользователя и пароль) для вашего сервера бронирования можно ввести на странице конфигурации сервера бронирования на партнерском портале . Пароли необходимо менять каждые шесть месяцев.

Примеры реализации скелета

Для начала ознакомьтесь со следующими примерами скелетов сервера бронирования, написанными для Node.js и Java-фреймворков:

• Скелет Node.js js-maps-booking-rest-server-v3-skeleton
• Скелет Java

Эти серверы отключили методы REST.

Требования

Ошибки HTTP и ошибки бизнес-логики

Когда ваш сервер обрабатывает HTTP-запросы, могут возникнуть ошибки двух типов.

• Ошибки, связанные с инфраструктурой или неправильные данные
  • Верните эти ошибки клиенту со стандартными кодами ошибок HTTP. См. полный список кодов состояния HTTP .
• Ошибки, связанные с бизнес-логикой
  • Верните код состояния HTTP, равный 200 OK, и укажите ошибку бизнес-логики в тексте ответа. Типы ошибок бизнес-логики, с которыми вы можете столкнуться, различны для разных типов реализаций сервера.

При интеграции списков ожидания резервирования ошибки бизнес-логики фиксируются в сбое бизнес-логики списка ожидания и возвращаются в ответе HTTP. Ошибки бизнес-логики могут возникнуть при создании ресурса, например при обработке метода CreateWaitlistEntry . Примеры включают, помимо прочего, следующее:

• ABOVE_MAX_PARTY_SIZE используется, когда запрошенная запись в списке ожидания превышает максимальный размер группы продавца.
• MERCHANT_CLOSED используется, когда список ожидания не открыт, поскольку продавец уже закрыт.

Идемпотентность

Связь по сети не всегда надежна, и Google может повторить HTTP-запросы, если ответ не получен. По этой причине все методы, изменяющие состояние, должны быть идемпотентными:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Для каждого сообщения запроса, кроме DeleteWaitlistEntry , включаются токены идемпотентности для уникальной идентификации запроса. Это позволяет вам различать повторный вызов REST с намерением создать один запрос и два отдельных запроса. DeleteWaitlistEntry однозначно идентифицируется по идентификаторам записей списка ожидания соответственно, поэтому в их запросы не включается токен идемпотентности.

Ниже приведены некоторые примеры того, как серверы бронирования обрабатывают идемпотентность:

• Успешный HTTP-ответ CreateWaitlistEntry включает идентификатор созданной записи списка ожидания. Если тот же CreateWaitlistEntryRequest получен второй раз (с тем же idempotency_token ), то должен быть возвращен тот же CreateWaitlistEntryResponse . Вторая запись в списке ожидания не создается и ошибка не возвращается.

  Обратите внимание: если попытка CreateWaitlistEntry завершается неудачей и тот же запрос отправляется повторно, в этом случае серверная часть должна повторить попытку.

Требование идемпотентности применяется ко всем методам, изменяющим состояние.