Uno degli obiettivi principali della progettazione di Websockets è che consente di comunicare sia i protocolli HTTP che Websocket sulla stessa porta. Ottiene ciò richiedendo esplicitamente a un client di eseguire un handshake Websocket con una richiesta di aggiornamento HTTP. In questo modo il server può gestire una connessione di richiesta HTTP standard e una richiesta di aggiornamento HTTP che ora viene aggiornata a una connessione duplex bidirezionale persistente.
Quindi sì, questo è sicuramente un caso d'uso valido, tuttavia se lo si deve fare per la propria applicazione specifica è completamente diverso. I Websocket sono utili e hanno senso laddove si hanno scenari in cui il server deve essere in grado di inviare dati non richiesti al client (feed live). Il protocollo HTTP ei servizi REST sono utili laddove si desidera bloccare la richiesta di dati sincroni da parte dei clienti.
Se i tuoi requisiti sono tali che entrambi hanno senso per la tua applicazione, allora devi usare tutti e due i metodi. Se tuttavia la tua unica interazione con il server è basata sul feed live, i servizi REST non sono appropriati. Penso che la facilità di debug dovrebbe essere di importanza piuttosto bassa in termini di Attributi di qualità del sistema su cui dovresti progettare il tuo design.