Определение синхронного и асинхронного в веб-приложениях

Вопрос:

Мне сказали, что лучшая практика гласит, что длительные HTTP-запросы должны быть превращены в более короткие асинхронные запросы с механизмом опроса для завершения.

Почему?

Важное различие:

Я работаю над API веб-сервисов. Это не предназначено для вызова браузерами (которые зависают при загрузке), а богатыми клиентами (которые асинхронно называют удаленные службы) и скриптами (которые могут выполнять один и тот же асинхронный трюк)

Мотивация:

Я хотел бы знать, потому что я пытаюсь принять решение относительно того, когда запрос должен быть сделан асинхронным, какова точка отсечки? Я работаю над веб-интерфейсом API, у которого есть запросы, которые берут от 0,001 секунды до 400 секунд (и везде между ними) в зависимости от запроса (а не от параметров, а от какого фактического метода они звонят).

Я мог бы сделать все асинхронным (за исключением опроса для завершения команды), но это усложняет работу, выполняемую клиентами API (т.е. получение результатов от запросов, опрос для завершения и т.д.).

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

Кроме того, все веб-службы, которые я использовал, похоже, следуют гибридной модели, поэтому они должны как-то принимать решение.

Единственный способ, которым я действительно мог ответить на этот вопрос, - это знать, почему эта лучшая практика существует.

Ответы

Ответ 1

Асинхронные API не блокируются. Каждый синхронный вызов ждет и блокирует ваши результаты, чтобы вернуться. Это просто спящий поток и потраченные впустую вычисления.

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

Асинхронные запросы - это способ масштабирования для тысяч одновременных пользователей.

но это усложняет работу, выполняемую клиентами API.

Это просто вопрос дизайна API. Как правило, вы можете позвонить в свой веб-API с обратным вызовом, чтобы справиться с этим. Опрос не требуется.

WebService.Call("someMethod" (data) -> {
   // do something when data returns.
});