Выбор сценария использования Web Sockets в стандартном HTTP REST API
Я буду рад получить совет от более опытных разработчиков по поводу добавления Web Sockets в мой проект, основанный на HTTP.
Вот в чем дело. Я разработал сервис на основе REST API. Все работает достаточно хорошо, но... В некоторых особых случаях моему серверу требуется много времени для обслуживания клиентских запросов. Это может быть от 1 минуты до нескольких часов (и даже дней)! Я реализовал не очень хороший алгоритм для решения этой проблемы:
- Клиент посылает HTTP запрос
- Сервер отвечает о регистрации запроса
- Клиент начинает посылать HTTP запросы для получения необходимых данных (если ответ не содержит нужной информации, клиент посылает другой запрос и так далее) Это все в двух словах.
Похоже, это плохой сценарий, и я пытаюсь интегрировать веб-сокеты для добавления дуплекс-каналов в эту архитектуру. Я надеюсь, что мой API сможет отправлять информацию об обновленных данных как можно быстрее без необходимости множества запросов от клиента.
Но я немного запутался в выборе одного из двух способов использования веб-сокета (WS).
Вариант A. Сервер только сообщает клиенту через WS, что данные готовы. А клиент получает данные стандартным методом запрос-ответ HTTP из REST API.
Вариант B. Сервер отправляет все данные клиенту через WS без HTTP вообще.
Какой вариант больше подходит? Или может быть какие-то другие варианты?
Я не хочу удалять HTTP вообще. Я просто пытаюсь реализовать WS для определенного типа конечных точек.
Вариант A был бы более подходящим и простым в реализации. Вы можете отправить сообщение клиенту после того, как данные будут готовы, и он сможет отправить запрос на получение данных. Это будет похоже на простой чат websocket, и будет служить вашей цели.