HTTP RESTful e websocket nella stessa applicazione?

Se un'applicazione ha già aperto un WebSocketfeed live, dovrei utilizzarlo AJAXper le altre comunicazioni con il server?

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

Preferisco le RESTful HTTPrichieste perché le trovo più facili da eseguire il debug. Puoi utilizzare un browser con URL o riccioli per testare ciò che restituisce l'API. Non è necessario scrivere codice per aprire a WebSocket.

Sarebbe strano avere RESTful HTTP APIe una WebSocketnella stessa applicazione?

rest ajax websockets

— Marc
fonte

"Non devi scrivere alcun codice per testare l'API" Potresti spiegarlo un po 'di più? Cosa ti fa pensare di non dover testare l'API?

— Elias Van Ootegem,

Chrome Developer Tools, se non sbaglio, ti consentono di aprire un websocket e inviare messaggi in tempo reale

— maple_shaft

@EliasVanOotegem Un buon punto. Mi dispiace che non fosse chiaro. Devi ancora testare l'API con un progetto unitario sul lato server. Quello che voglio dire è che se vuoi dare una rapida occhiata a cosa restituirebbe l'API, puoi usare un broswer con l'URL. Non è necessario scrivere codice per aprire un websocket. Ho aggiornato la mia domanda.

— Marc

@maple_shaft Va bene, ma è necessario trovarsi su una pagina con un WebSocket aperto sul server.

— Marc

Uno degli obiettivi di progettazione principali di Websocket è che consente di comunicare sia i protocolli HTTP che Websocket sulla stessa porta. Ciò si ottiene richiedendo esplicitamente a un client di eseguire una stretta di mano Websocket con una richiesta di aggiornamento HTTP. In questo modo il server è in grado di gestire una connessione 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 DOVREBBE farlo per la tua specifica applicazione è completamente diverso. I websocket sono utili e hanno senso quando si hanno scenari in cui il server deve avere la capacità di inviare dati non richiesti al client (feed live). Il protocollo HTTP e i servizi REST sono utili dove si desidera bloccare la sollecitazione sincrona dei dati da parte dei client.

Se le tue esigenze sono tali che entrambe hanno senso per la tua applicazione, allora dovresti usare entrambe. Se tuttavia la tua unica interazione con il server è basata su feed live, i servizi REST non sono appropriati. Penso che la facilità di debug dovrebbe avere un'importanza piuttosto bassa in termini di Attributi di qualità del sistema su cui dovresti progettare il tuo progetto.

— albero_acero
fonte

Questo è quello che mi chiedevo. Ha senso utilizzare websocket per feed live in tempo reale, ma per quanto riguarda le operazioni CRUD? Per me ha più senso usare una richiesta HTTP standard per quelli.

— Marc,

@Marc, non troverei strano separare le operazioni CRUD e le preoccupazioni in tempo reale (una usando HTTP l'altra Websocket) ... ma credo che otterrai una migliore reattività dal server, così come prestazioni migliori, se si utilizza la connessione persistente (Websocket) per tutte le operazioni. Questo dipende davvero dalle esigenze del tuo CRUD, ma non vorrei rifuggire da un'interfaccia CRUD Websocket.

— Myst,

upvoted! novizio qui, dal momento che hai menzionato entrambi devono essere comunicati sulla stessa porta, se stai recuperando diciamo i prezzi delle azioni da un flusso live e a causa del traffico intenso il flusso si disconnette per alcuni minuti, come vorresti ottenere i dati tra o cosa esistono strategie per affrontare quel caso

— PirateApp il