Стандартные процессы работы API

Из этой статьи вы узнаете о типичных этапах взаимодействия с API, например добавлении класса, сохранении или обновлении объекта. Реализацией всех операций между браузером, вашим сервером и Google Pay API for Passes вы занимаетесь самостоятельно. Процессы работы с разными картами и билетами практически одинаковы. В качестве примера на диаграмме ниже представлен процесс взаимодействия с объектом LoyaltyObject.

Рисунок 1. Процесс работы API.

Стандартный процесс работы API с кнопками JavaScript и ссылками на JWT

Этот процесс изображен на диаграмме выше. Также вы можете ознакомиться с его описанием:

1. Продавец создает LoyaltyClass карты постоянного клиента.
1. Сервер определяет переменные LoyaltyClass.
2. Сервер отправляет запрос POST на добавление LoyaltyClass на сервер Google Pay API.
Примечание. Если вы используете кнопку JavaScript, этот шаг может не выполняться. Поскольку ограничения по символам нет, добавлять класс заранее не обязательно. Однако будет лучше, если вы это сделаете: тогда класс можно будет использовать несколько раз. Обычно это самый удобный метод работы с картами постоянного покупателя.
2. По запросу сервера сервис создает веб-токен JSON для объекта LoyaltyObject в определенном классе LoyaltyClass. Этот объект представляет собой карту постоянного клиента конкретного пользователя.
1. Ваш сервер использует JWT для добавления кнопки Сохранить в Google Pay (S2GP).
• На сайтах размещайте кнопку JavaScript.
• Для электронных писем, SMS и оригинальных приложений используйте ссылку JWT с кнопкой "Сохранить в Google Pay".
3. Пользователь нажимает кнопку Сохранить в Google Pay на сайте, в электронном письме, оригинальном приложении или SMS от продавца карты постоянного клиента.
1. Пользователь попадает на целевую страницу с предложением сохранить объект LoyaltyClass. Объект для сохранения отображается на целевой странице согласно настройке JWT. Если пользователь нажал кнопку в оригинальном приложении, ему будет предложено сохранить объект в Google Pay.
2. Затем он нажимает кнопку Сохранить в Google Pay на ресурсе продавца, чтобы добавить объект LoyaltyObject в приложение.
3. Объект LoyaltyObject добавляется на сервер Google, а затем в приложение Google Pay. Объект LoyaltyObject получает название "Карта постоянного клиента".
Примечание. В какой-то момент пользователь сохранит данные, или на сервер впервые отправится REST-запрос на добавление либо объекта LoyaltyClass, либо объекта LoyaltyObject. Когда это произойдет, последующие JWT с таким же параметром classID или objectID будут представлять то, что уже добавлено на сервер Google. Если вы измените информацию о существующем параметре classID или objectID в JWT, данные не обновятся. Процесс внесения изменений для существующих классов и объектов описан в шаге 4.
4. Продавец обновляет информацию о карте.
1. Продавец создает запрос GET для LoyaltyObject, используя Object.id.
2. Затем продавец обновляет объект LoyaltyObject.
3. Продавец создает запрос PUT или PATCH, чтобы добавить обновленный объект LoyaltyObject на сервер Google Pay API for Passes.
4. Объект LoyaltyObject помещается в приложение Google Pay.

Сокращенный вариант ссылки на JWT

В браузерах данные усекаются, поэтому JSON-токены в ссылках не должны превышать 1800 символов. Если соблюдать лимит не получается, советуем сначала добавить класс и объект, тогда в JWT будет только поле object id.

Примечание. Вставлять класс и объект следует только после того, как пользователь согласится добавить карту или билет в Google Pay. Чтобы инициировать процесс сохранения, рекомендуем задать собственную ссылку для сохранения элемента.

На диаграмме ниже показан процесс работы с API, который позволяет добавить кнопку "Сохранить в Google Pay" в электронное письмо или SMS.

Рисунок 2. Процесс работы API с сокращенным вариантом ссылки на JWT.

Процесс работы API с методом запроса POST с JWT

Мы понимаем, что зачастую непросто внедрить систему, благодаря которой классы создаются до сохранения объектов. Однако если этого не сделать, веб-токены JSON наверняка превысят лимит в 1800 символов. Именно поэтому лучше использовать метод запроса POST с JWT. В таком случае из вашего приложения можно будет сохранять объекты, для которых создается большое количество классов, например, билеты на мероприятия, посадочные талоны и не только.

Примечание. Метод запроса POST с JWT можно использовать при сохранении объекта из вашего приложения, но не из SMS или электронного письма, так как для этого используется вызов POST.

Ниже представлены этапы работы с классом flight:

1. Ваш сервер создает JWT для ресурсов FlightObject и FlightClass. Оба типа ресурсов определяются в коде JSON, при этом FlightObject ссылается на FlightClass.
2. С вашего сервера JWT отправляется в клиентское приложение с кнопкой Сохранить в Google Pay. Обратите внимание, что она должна соответствовать правилам фирменного оформления Google.
3. Пользователь нажимает в вашем приложении кнопку "Сохранить в Google Pay".
   1. Создается запрос POST, который отправляется конечной точке JWT. Это позволяет добавить идентификаторы класса и объекта. Если идентификаторы класса и объекта в системе уже существуют, они не будут в нее добавлены повторно. О том, как их можно изменить, написано в нашем руководстве. Если вы попытаетесь добавить идентификаторы, которые уже сохранены, сообщение об ошибке показано не будет.
   2. Появляется URI-ответ, который доступен пользователю: так он сможет сохранить посадочный талон. URI действует в течение недели после появления запроса.

Чтобы внедрить API, используйте метод запроса POST с JWT.

Рисунок 3. Диаграмма запроса POST с JWT.

На рисунке 3 нет стрелок между столбцами Your server (Ваш сервер) и Google server (Сервер Google). В этом заключается основное отличие метода запроса POST с JWT от метода ссылки на JWT и намерения. Для обновления информации о картах и билетах мы рекомендуем использовать связь от сервера к серверу.