Для загрузки блогов есть вызов API GET.Мобильное приложение вызывает этот API несколько раз одновременно - более 500 вызовов.Несмотря на то, что большинство постов успешно загружены, если размер нескольких блогов огромен, загрузка не удалась из-за тайм-аута.
Текущий дизайн:
- Mobile делает сотни вызовов API одновременно
- В случае успеха каждый вызов API возвращает содержимое поста блога в формате json с кодом состояния 200 OK
- API имеет ограничение в байтах, которое он может загружать одновременно
- Когда размер и размеробщее количество блогов в целом огромно, тогда тайм-ауты API, поскольку он не может загрузить больше пороговых байтов
Ожидаемый дизайн:
- API не должен возвращать содержимое блогас 200 OK
- Вместо этого он должен просто вернуть 202 Принятый (содержимое блога не должно возвращаться) вместе с местоположением, например '/ api / blogpost / queue / 1'
- '/api / blogpost / queue / 1 '- эта ссылка должна возвращать текущий статус загрузки блога (50%, 80%, оставшееся время и т. д.)
- После завершения загрузки запросЭтот ресурс должен быть удален.Если клиент хочет получить статус снова, он должен вернуть '303 See Other' со ссылкой на исходный ресурс blogpost - '/ api / blogpost / 1'
(см. * 1028).* & https://www.jerriepelser.com/blog/communicate-status-background-job-signalr/)
Как должен выполняться реальный код для загрузки блогов (длительная задача)? В качестве отдельного веб-API? Или в качестве фоновой задачи? Или я должен использовать SignalR? Какой подход будет лучше?«Я не беспокоюсь об интерфейсе пользователя. Я делаю все эти вызовы API через Почтальон. Пожалуйста, сообщите, если необходимо предоставить больше информации.
РЕДАКТИРОВАТЬ:
В двух словах, загрузка блогов не должнавлияет на другие действия в мобильном приложении. Если блог-посты пытаются загрузить, они должны быть загружены на 100%. Пусть это займет любое время. Он не должен блокировать мобильное приложение. Пользователь должен иметь возможность проверять статус загрузкииз всех этих постов.