Вам необходимо настроить сервер бронирования, чтобы Центр действий мог выполнять обратные вызовы для создания и обновления бронирований от вашего имени.
- Реализация списков ожидания резервирования. Это используется, когда вы участвуете в пилотной программе списков ожидания резервирования. Это позволяет Центру действий получать оценки ожидания и создавать записи в списке ожидания от имени пользователя.
- Стандартная реализация. Это позволяет Центру действий создавать встречи, заказы и резервирования у вас от имени пользователя. Чтобы реализовать сервер бронирования для сквозной интеграции Reservations, ознакомьтесь с разделом «Реализация сервера бронирования» .
Обратитесь к документации партнерского портала , чтобы узнать, как настроить подключение к песочнице и производственным серверам бронирования.
Реализуйте интерфейс REST API.
Внедрите интерфейс API на основе REST. Это позволяет Google отправлять запросы к серверу бронирования через HTTP.
Для начала настройте сервер резервирования для разработки или изолированной программной среды, который можно подключить к изолированной среде Actions Center. Переходите в производственную среду только после полного тестирования песочницы.
Методы
Для каждого типа сервера бронирования с вашей стороны требуется свой набор методов API. При желании вы можете скачать определение сервиса в формате прототипа, чтобы начать реализацию API. В следующих таблицах показаны методы для каждой реализации и приведены ссылки на форматы прототипов служб.
Реализация списка ожидания |
---|
Определение службы списка ожидания . Загрузите файл определения прото-сервиса. |
Метод | HTTP-запрос |
---|---|
Проверка здоровья | ПОЛУЧИТЬ /v3/HealthCheck/ |
BatchGetWaitОценки | POST/v3/BatchGetWaitEstimates/ |
Создать запись в списке ожидания | POST/v3/CreateWaitlistEntry/ |
Получить запись в списке ожидания | POST/v3/GetWaitlistEntry/ |
Удалить запись в списке ожидания | POST/v3/DeleteWaitlistEntry/ |
API-ресурсы
Список ожидания
Для реализации бронирования на основе списка ожидания используются следующие ресурсы:
- WaitEstimate : оценка ожидания для определенного размера группы и продавца.
- WaitlistEntry : запись пользователя в списке ожидания.
Поток: создать запись в списке ожидания
В этом разделе описано, как создать бронирование для интеграции списков ожидания резервирования.
![Рисунок 2. Рабочий процесс создания записи в списке ожидания.](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=7&hl=ru)
Когда пользователь создает запись в списке ожидания, 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, равный
При интеграции списков ожидания резервирования ошибки бизнес-логики фиксируются в сбое бизнес-логики списка ожидания и возвращаются в ответе HTTP. Ошибки бизнес-логики могут возникнуть при создании ресурса, например при обработке метода CreateWaitlistEntry
. Примеры включают, помимо прочего, следующее:
-
ABOVE_MAX_PARTY_SIZE
используется, когда запрошенная запись в списке ожидания превышает максимальный размер группы продавца. -
MERCHANT_CLOSED
используется, когда список ожидания не открыт, поскольку продавец уже закрыт.
Идемпотентность
Связь по сети не всегда надежна, и Google может повторить HTTP-запросы, если ответ не получен. По этой причине все методы, изменяющие состояние, должны быть идемпотентными:
-
CreateWaitlistEntry
-
DeleteWaitlistEntry
Для каждого сообщения запроса, кроме DeleteWaitlistEntry
, включаются токены идемпотентности для уникальной идентификации запроса. Это позволяет вам различать повторный вызов REST с намерением создать один запрос и два отдельных запроса. DeleteWaitlistEntry
однозначно идентифицируется по идентификаторам записей списка ожидания соответственно, поэтому в их запросы не включается токен идемпотентности.
Ниже приведены некоторые примеры того, как серверы бронирования обрабатывают идемпотентность:
Успешный HTTP-ответ
CreateWaitlistEntry
включает идентификатор созданной записи списка ожидания. Если тот жеCreateWaitlistEntryRequest
получен второй раз (с тем жеidempotency_token
), то должен быть возвращен тот жеCreateWaitlistEntryResponse
. Вторая запись в списке ожидания не создается и ошибка не возвращается.Обратите внимание: если попытка
CreateWaitlistEntry
завершается неудачей и тот же запрос отправляется повторно, в этом случае серверная часть должна повторить попытку.
Требование идемпотентности применяется ко всем методам, изменяющим состояние.