Python-сообщество

Здравствуйте.
Есть задача сделать api для общения с другими api.
Ситуация такая клиент посылает запрос на api (который мы пишем), наш api обрабатывает этот запрос и для получения доп. инфы отправляет запрос другому api(внешний), но не получает ответ сразу. Наш api ждёт пока внешний api подготовит ответ. Наш api получил тикет(id запроса) по которому он может сделать запрос и получить состояние (готов ли ответ или нет). Как только наш api в очередной раз дёрнул внешний api на предмет готовности ответа (ответ готов). Наш api формирует ответ и засылает его клиенту.
И в связи с эти в данной схеме много ожиданий как клиента так и нашего api. Как не блокировать наш api чтобы обрабатывать другое запросы? Как построить ответы клиенту чтобы клиент тоже не зависал в ожидании ответа от нашего api ( может по принципу такому как наш api ждёт ответа от внешнего?)
Нужно использовать aiohttp?
Спасибо за умные мысли.

Отредактировано freeddos (Фев. 2, 2020 18:30:00)

Скорее всего, придётся тебе очередь сообщений иметь, которая где-то хранится и к которой можно доступ получать независимо от активности сервисов, работающих с ней. Брокер сообщений.

Правильно ли я понимаю, что у меня должно быть хранилище запросов которые в обработке как от нашего api до внешнего, так и запросы от клиента.
Когда наш api получает запрос от клиента, то мы в очередь помещаем этот запрос, для того чтобы потом на него ответить. Потом формируем запрос во внешний api, так же записываем в другую очередь запрос к внешнему api. в очередях должна быть какая то связь между этими запросами (чтобы ответить клиенту на сделанный им запрос). После чего сервер по крону смотрит запросы от клиентов (которые не обработаны) потом по связи с этим запросом ищет запрос к внешнему api чтобы дернуть внешний api на предмет того “нет ли отчета” по запросу клиента. Если ответ есть то формируем ответ для клиента. И тут возникает вопрос “а как клиент узнает об ответе?” (то есть клиент сам должен по крону дергать http ручку нашего на предмет того а не готов ли ответ).
Как лучше это организовать? в виде отдельных таблиц в базе?

freeddos
а как клиент узнает об ответе?

есть несколько решений, зависит от клиента
1. Опрос сервера по таймеру
2. Long polling
3. Web-sockets
4. Webhooks

Клиент пока не известен (скорей всего это будет или веб (react, vue) или десктоп(что нибудь на C#) или вообще 1С клиент).
Клиент отослав запрос должен будет дождаться ответа. То есть он не будет так делать запрос отправил, закрыл приложение и зашел чтобы проверить дела.

И так же правильное ли направление мыслей по очередям, что нужно хранить запросы как клиентов так и к внешнему api (ну и связь между ними). А потом по исполнению запроса удалить из очередей запросы.

freeddos
Клиент пока не известен (скорей всего это будет или веб (react, vue) или десктоп(что нибудь на C#) или вообще 1С клиент).

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

Да может быть несколько видов клиентов, поэтому api по идее все равно должно быть какой клиент будет, главное чтобы протокол общения был один и это будет http (через json).