websocket по умолчанию не работает в режиме запрос-ответ. это именно возможность быстро отправлять события на вторую половину приложения. то есть как правило отправляется название события и его данные payload.
отправка события не всегда предполагает необходимость ответа, как правило отправка клиентом события на сервер порождает события для других клиентов.
rest при желании можно завернуть, но это будет именно rest поверх websocket, а не rest-websocket. то есть отправляете сообщение содержащее метод, endpoint, params, id_request(для того чтобы сопоставить ответ с запросом на клиенет) и тд. в вебсокет а на сервере это все разбирать и роутить.
для нового проекта смысла в этом конечно мало, можно проще сделать, а семантичность тут ни к чему. для старого проекта можно сделать чтобы не переписывать всю бизнес логику проекта, а просто сделать ф-ю которая аналогично fetch/axios делает аналогичные запросы только через websocket.
воспринимайте websocket как систему обмена сообщениями(событиями), а не запрос-ответ.
