3.1.4. Запросы в формате JSON¶

3.1.4.1. Адаптация конфигурации из базового примера¶

Поскольку базовый пример использует JSON, то адаптация конфигурации системы из базового примера не потребуется.

3.1.4.2. Описание процесса обработки запроса¶

Логика обработки поступающего запроса изложена в файле конфигурации системы config.yml и состоит в следующем:

• Согласно разделу connector / input файла конфигурации config.yml HTTP (JSON) запросы передаются на обработку конвейеру router, который состоит из функции router;

• Функция router ссылается на файл router.lua, который упаковывает поступивший объект с ключом routing_key равным строке input_key;

• Согласно разделу connector / routing файла конфигурации config.yml, все объекты с ключом input_key передаются to_input_processor;

• В секции output для раздела connector указана единственная запись to_input_processor, которая переадресует запрос в раздел input_processor для обработки на одноименной роли;

• В разделе input_processor все запросы попадают в секцию classifiers, где в нашем случае указан один единственный объект, вызывающий конвейер (pipeline) classifier;

• Конвейер classifier вызывает одноименную функцию, которая описана в файле classificator.lua. Как можно понять из названия, данная функция занимается классификацией поступающей информации. Логика ее работы следующая:

  • при наличии ненулевого поля username у поступившего объекта — ему присваивается routing_key = add_user. Для объектов с таким ключом в config.yml предусмотрено сохранение (на роли storage) объекта с типом User из модели данных;

  • при наличии ненулевого поля book_name у поступившего объекта — ему присваивается routing_key = add_book. Для объектов с таким ключом в config.yml предусмотрено сохранение (на роли storage) объекта с типом Book из модели данных;

  • при наличии ненулевых полей user_id и book_id у поступившего объекта — ему присваивается routing_key = add_subscription. Для объектов с таким ключом в config.yml предусмотрено сохранение (на роли storage) объекта с типом Subscription из модели данных;

  • во всех остальных случаях объекту присваивается routing_key = unknown_type, то есть объект не распознан. Такой объект обычно попадает в ремонтную очередь, но можно настроить и иное поведение;

• В секции storage описано сохранение данных в TDG.

  • при значении routing_key равном add_user поступивший объект преобразовывается в тип User при сохранени;

  • при значении routing_key равном add_book поступивший объект преобразовывается в тип Book при сохранени;

  • при значении routing_key равном add_subscription поступивший объект преобразовывается в тип Subscription при сохранении.

Обратите внимание, что вся лишняя информация, не относящаяся к типу объекта, описанному в модели данных, не будет сохранена.

Из всего файла конфигурации системы остался не рассмотренным участок, отвечающий за сервисы. В данном примере там описан простой сервис, вызывающий функцию select_user_books с аргументом user_id и возвращающий строковую переменную.

Логика работы этой функции такова: переданное значение user_id используется для поиска в объекте Subscription всех книг, записанных за данным пользователем. Затем выводятся все найденные book_id.

3.1.4.3. Подготовка запроса в формате JSON¶

Создайте файл request.py со скриптом на языке Python для отправки простейшего запроса с полями объекта типа User (из нашей модели данных: это поля id и username), который будет выглядеть следующим образом:

import requests

data = {'username' : 'John Smith', 'id' : 1}
header = {'Authorization' : 'Bearer ee7fbd80-a9ac-4dcf-8e43-7c98a969c34c'}

r = requests.post(url = "http://172.19.0.2:8080/http", json = data, headers = header)

Для успешного добавления записи имеющегося в модели данных типа объекта в запросе должны содержаться все обязательные поля для данного типа объекта.

Процедура отправки запроса и ожидаемые результаты описаны ранее в пункте Отправка запросов.