RESTful HTTP e websocket nella stessa applicazione?

12

Se un'applicazione ha già aperto WebSocket per i feed live, dovrei usarla oltre AJAX per le altre comunicazioni con il server?

Poiché la connessione è già aperta, dovremmo usarla per le richieste che sono Request/Response e non in tempo reale?

Preferisco le richieste di RESTful HTTP perché le trovo più facili da eseguire il debug. Puoi utilizzare un browser con URL o riccioli per testare cosa restituisce l'API. Non devi scrivere codice per aprire WebSocket .

Sarebbe strano avere RESTful HTTP API e WebSocket nella stessa applicazione?

    
posta Marc 29.04.2016 - 14:29
fonte

1 risposta

12

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.

    
risposta data 29.04.2016 - 15:05
fonte

Leggi altre domande sui tag