Недавно я опубликовал JsonBatch — движок для выполнения пакетных запросов с помощью REST API на основе JSON. Несмотря на то, что это небольшая библиотека, я счел вполне удовлетворительным пройти через все процессы, начиная с проектирования и заканчивая ее разработкой. Итак, сегодня я хочу поделиться с вами своим путешествием.
I. Идея
Все началось с требования к продукту нашей компании. Чтобы помочь одному из наших пользователей перенести свою собственную систему в нашу систему, нам необходимо предоставить им адаптер, который устранит разрыв между их API-интерфейсами и нашими API-интерфейсами и будет поддерживать его некоторое время, пока они не завершат процесс миграции.
Это обычное требование, но мы хотим каким-то образом использовать его повторно, чтобы нам не приходилось повторять одни и те же работы с другими пользователями. Сначала мы подумали о том, чтобы предоставить пользователю способ настроить, к какой конечной точке будет перенаправляться их API, и как сопоставить наш ответ с их ответом. Довольно прямолинейно, но реальность не так проста. Из-за разной конструкции 2 систем их API в основном придется вызывать несколько запросов, а затем агрегировать все ответы.
Вот тогда-то мне и пришла в голову идея. Что нам нужно, так это пакетный движок, который можно легко и динамически настраивать.
ii. Первый прототип
Таким образом, для пакетного движка он должен принимать список запросов, выполняться последовательно и собирать все ответы.
Логика выполнения проста, но здесь возникает первая проблема: Как создать тело запроса? Это легко, если клиент может предоставить все тела запросов, но что, если тело запроса требует данных из ответа на другой запрос? Движку нужен способ узнать, как и где извлекать данные. Потому что все запросы и ответы будут в формате JSON, поэтому, если вы хотите найти поле, первый ответ, который пришел ко мне, – это использование JSONPath. К счастью, в Java уже есть хорошая библиотека Jayway JSONPath , который поддерживает все мои потребности.
Итак, теперь мы закончили с Как вопрос, следующий вопрос Где . Решение, которое я придумал, заключается в создании большого JSON, содержащего все запросы и ответы. Что-то вроде этого:
{
"original": {
"http_method": "...",
"url": "...",
"headers": {
"header_1": [ "..." ],
"header_2": [ "..." ],
...
},
"body": { ... }
},
"requests": [
{
"http_method": "...",
"url": "...",
"headers": {
"header_1": [ "..." ],
"header_2": [ "..." ],
...
},
"body": { ... }
},
...
],
"responses": [
{
"status": ...,
"headers": {
"header_1": [ "..." ],
"header_2": [ "..." ],
...
},
"body": { ... }
},
...
]
}
При этом остается только 1 проблема: нам нужен формат схемы, чтобы дать команду движку создать фактическое тело JSON. Быстрый поиск и я обнаружил схему JSON. Но после некоторых исследований я думаю, что схема JSON больше подходит для проверки, чем для генерации, и формат схемы имеет структуру, которая сильно отличается от фактического JSON. Так что мне остается разработать свою собственную пользовательскую схему.
Проведя несколько экспериментов, я пришел к простой, но достаточно хорошей схеме. Схема такая же, как и в реальном JSON, но только поле string имеет определенный формат. Например:
{
"field_1": 1,
"field_2": "int $.responses[0].body.field_a",
"field_3": "int[] $.responses[*].body.field_a"
}
С помощью этой схемы движок создаст JSON с:
- поле_1
- field_2 является целым числом и извлекает значение из JSONPath: $.responses[0].body.field_a
- field_3 является целочисленным массивом и извлекает значение из JSONPath: $.responses[*].body.field_a
Фактический JSON будет выглядеть так:
{
"field_1": 1,
"field_2": 2,
"field_3": [2, 3, 4]
}
Вы можете видеть, что структура schema & actual очень похожа.
Теперь, после того, как все части собрались вместе, мне потребовалось около 1 недели, чтобы закодировать этот первый прототип. В следующей части я расскажу о том, как этот прототип продолжает развиваться.
Первоначально опубликовано на Первоначально опубликовано на
Оригинал: “https://dev.to/rey5137/jsonbatch-journey-from-zero-to-full-fledged-batch-engine-part-1-578o”