Шаг 4. Внедрите сервер бронирования

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

• Стандартная реализация. Это позволяет Центру действий создавать встречи, заказы и резервирования у вас от имени пользователя.

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

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

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

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

Методы

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

Стандартная реализация
Определение стандартного сервиса Загрузите файл определения прототипа сервиса.

Метод	HTTP-запрос
Проверка здоровья	ПОЛУЧИТЬ /v3/HealthCheck/
Пакетная доступность	POST/v3/BatchAvailabilityLookup/
Создать бронирование	POST/v3/CreateBooking/
ОбновлениеБронирование	ПОСТ /v3/UpdateBooking/
GetBookingStatus	POST/v3/GetBookingStatus/
ListBookings	ПОСТ /v3/ListBookings/

API-ресурсы

Бронирование

В стандартной реализации используются следующие типы ресурсов:

• Слот : слот инвентаря.
• Бронирование : Назначение слота инвентаря.

Ход: создать бронирование

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

Рисунок 1. Рабочий процесс создания бронирования из слота.

Когда пользователь создает бронирование, 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. Ошибки бизнес-логики могут возникнуть при создании или обновлении ресурса. Например, когда вы обрабатываете методы CreateBooking или UpdatingBooking . Примеры включают, помимо прочего, следующее:

• SLOT_UNAVAILABLE используется, если запрошенный слот больше не доступен.
• PAYMENT_ERROR_CARD_TYPE_REJECTED используется, если указанный тип кредитной карты не принимается.

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

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

• CreateBooking
• UpdateBooking

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

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

• Успешный HTTP-ответ CreateBooking включает созданное бронирование. В некоторых случаях платеж обрабатывается как часть процесса бронирования. Если тот же CreateBookingRequest получен во второй раз (с тем же idempotency_token ), то должен быть возвращен тот же CreateBookingResponse . Второе бронирование не создается, и с пользователя взимается плата только один раз, если это применимо.

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

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