Как лучше организовать API для работы с websockets?

Question

[beduin01]

По всех примерах работы с WebSockets приводится один единственный энд-поинт вида:
/ws

С которым в примерах идёт взаимодействие. А как в реальных проектах? Тоже один используется и дальше идёт маршрутизация на базе входящих данных? Или все подход используется подобный REST где для каждой сущности свой эндпоинт?

Answer 1

[Юрий]

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

Answer 2

[Дмитрий Беляев]

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