Трио методов для асинхронных процессов

Постановка задачи следующая: дать возможность запускать некий асинхронный процесс на сервере, проверять его состояние и получать результат.

Хороший пример: запуск поиска со множеством параметров по множеству API c последующим разбором результатов через адаптеры. Сам процесс нас не волнует, лишь рычаги управления: допустим, метод run или search (что-то вроде ‘http://site.com/api/v1/run’ ) принимает через POST множество параметров для запуска, а возвращает id.

051091cbc58b2d3c549adbd0168cb3db

Окей, что нам делать с этим id? Нам его нужно отдавать тому же серверу, чтобы 1) смотреть, что он сделал по нашему запросу 2) брать информацию, когда он всё сделал.

Хорошая идея (и, возможно, первая, которая приходит в голову) — сделать ещё два метода, например, check (или status, я просто привык именовать методы глаголами, для REST это неприемлемо) — ‘http://site.com/api/v1/check/id‘. И get-results — ‘http://site.com/api/v1/get-results/id‘.

Зачем нам нужен check? Чтобы проверять, в каком состоянии находится запущенный процесс с полученным из метода run id. А get-results чтобы получать результаты.

Можно решить эту задачу двумя методами: и правда, зачем вообще нужен check, если у нас есть метод get-results, который просто не вернёт информацию, если её нет. Его можно нагрузить дополнительной логикой и возвращать status как один из ключей ответа. Преимущество такого метода интуитивно понятно:

bef78d760a87e6aab392cff755a8ff0d

В то время, как запросы должны с некой переодинчностью проверять Check, чтобы убедиться в наличии данных, а лишь потом спрашивать сами данные, вариант с двумя методами позволяет получить данные сразу, подгадав нужный момент. То есть, мы избавимся от одного потенциально лишнего запроса.

Но это не панацея для всех проблем такого вида: если процесс поиска составной, и в фоне запускается несколько потоков для выгрузки разнородной информации, то метод get-results может вернуть лишь часть результатов. К примеру, поиск по транспортным средствам, где самолёты и автомобили доступны с разных API — тогда самолёты могут найтись, а автомобили нет. Получится такая ситуация, что мы лишний раз нагружаем сервер, вытаскиваем полученные результаты, а они оказываются слишком громоздкими или неполными, и нам придётся делать ещё один запрос, чтобы получить более полную информацию. Само собой, можно спроектировать метод get-results так, чтобы он сводил потери такого вида к минимуму, но гораздо проще в сопровождении будет отделение статистики и статуса процесса поиска в отдельный метод: check. Он может возвращать статистику: сколько уже найдено, минимальная и максимальная цена \ вес \ что-либо ещё из нужных параметров, при этом не станет затрагивать сами данные.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *