Вам необходимо настроить сервер бронирования, чтобы Центр действий мог выполнять обратные вызовы для создания и обновления бронирований от вашего имени.
- Стандартная реализация. Это позволяет Центру действий создавать встречи, заказы и резервирования у вас от имени пользователя.
Обратитесь к документации партнерского портала , чтобы узнать, как настроить подключение к песочнице и производственным серверам бронирования.
Реализуйте интерфейс 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. Рабочий процесс создания бронирования из слота.](https://developers.google.cn/static/actions-center/images/rest_api_v3_booking_flow_1.png?authuser=9&hl=ru)
Когда пользователь создает бронирование, 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. Ошибки бизнес-логики могут возникнуть при создании или обновлении ресурса. Например, когда вы обрабатываете методы CreateBooking
или UpdatingBooking
. Примеры включают, помимо прочего, следующее:
-
SLOT_UNAVAILABLE
используется, если запрошенный слот больше не доступен. -
PAYMENT_ERROR_CARD_TYPE_REJECTED
используется, если указанный тип кредитной карты не принимается.
Идемпотентность
Связь по сети не всегда надежна, и Google может повторить HTTP-запросы, если ответ не получен. По этой причине все методы, изменяющие состояние, должны быть идемпотентными:
-
CreateBooking
-
UpdateBooking
Для каждого сообщения запроса, кроме UpdateBooking
, включаются токены идемпотентности для уникальной идентификации запроса. Это позволяет вам различать повторный вызов REST с намерением создать один запрос и два отдельных запроса. UpdateBooking
однозначно идентифицируется по идентификаторам записей бронирования соответственно, поэтому в их запросы не включается токен идемпотентности.
Ниже приведены некоторые примеры того, как серверы бронирования обрабатывают идемпотентность:
Успешный HTTP-ответ
CreateBooking
включает созданное бронирование. В некоторых случаях платеж обрабатывается как часть процесса бронирования. Если тот жеCreateBookingRequest
получен во второй раз (с тем жеidempotency_token
), то должен быть возвращен тот жеCreateBookingResponse
. Второе бронирование не создается, и с пользователя взимается плата только один раз, если это применимо.Обратите внимание: если попытка
CreateBooking
завершается неудачей и тот же запрос отправляется повторно, в этом случае серверная часть должна повторить попытку.
Требование идемпотентности применяется ко всем методам, изменяющим состояние.