API Websocket per sostituire l’API REST?

Ho un’applicazione la cui funzione primaria funziona in tempo reale, tramite websocket o polling lungo.

Tuttavia, la maggior parte del sito è scritta in modo RESTful, che è bello per applicazioni e altri client in futuro. Tuttavia, sto pensando di passare a un’API websocket per tutte le funzioni del sito, lontano da REST. Ciò mi renderebbe più facile integrare funzionalità in tempo reale in tutte le parti del sito. Questo renderebbe più difficile creare applicazioni o client mobili?

Ho scoperto che alcune persone stanno già facendo cose del genere: SocketStream

Per non dire che le altre risposte qui non hanno valore, fanno alcuni buoni punti. Ma ho intenzione di andare contro il consenso generale e sono d’accordo con te sul fatto che passare alle websocket per qualcosa di più delle semplici funzionalità in tempo reale è molto allettante.

Sto seriamente pensando di spostare la mia app da un’architettura RESTful a più di uno stile RPC tramite websocket. Questa non è una “app giocattolo”, e non sto parlando solo di funzionalità in tempo reale, quindi ho delle riserve. Ma vedo molti vantaggi nel percorrere questa strada e ritengo che potrebbe rivelarsi una soluzione eccezionale.

Il mio piano è usare DNode , SocketIO e Backbone . Con questi strumenti, i miei modelli e collezioni Backbone possono essere passati da / a client e server semplicemente chiamando una funzione in stile RPC. Niente più gestione degli endpoint REST, serializzazione / deserializzazione di oggetti e così via. Non ho ancora lavorato con socketstream, ma sembra che valga la pena di provarlo.

Ho ancora molta strada da fare prima di poter dire definitivamente che questa è una buona soluzione, e sono sicuro che non è la soluzione migliore per ogni applicazione, ma sono convinto che questa combinazione sarebbe eccezionalmente potente. Ammetto che ci sono alcuni svantaggi, come perdere la capacità di memorizzare nella cache le risorse. Ma ho la sensazione che i vantaggi saranno superiori a loro.

Sarei interessato a seguire i tuoi progressi nell’esplorare questo tipo di soluzione. Se hai qualche esperimento di GitHub, per favore indicami. Non ne ho ancora, ma spero di presto.

Di seguito è riportato un elenco di collegamenti successivi alla lettura che ho raccolto. Non posso garantire che vadano tutti bene, dato che ho sfogliato solo molti di loro. Ma si spera che alcuni aiuteranno.


Ottimo tutorial sull’utilizzo di Socket.IO con Express. Espone sessioni espresse a socket.io e discute come avere stanze diverse per ogni utente autenticato.

Esercitazione su node.js / socket.io / backbone.js / express / connect / jade / redis con autenticazione, hosting Joyent, ecc .:

Esercitazione sull’uso di Pusher con Backbone.js (usando Rails):

Crea un’applicazione con backbone.js sul client e node.js con express, socket.io, dnode sul server.

Utilizzo di Backbone con DNode:

HTTP REST e WebSockets sono molto diversi. HTTP è senza stato , quindi il server web non ha bisogno di sapere nulla e si ottiene il caching nel browser web e nei proxy. Se si utilizzano WebSockets, il server diventa statico e occorre avere una connessione al client sul server.

Comunicazione richiesta-risposta vs Push

Utilizzare WebSockets solo se è necessario inviare i dati PUSH dal server al client, tale modello di comunicazione non è incluso in HTTP (solo per soluzioni alternative). PUSH è utile se gli eventi creati da altri client devono essere disponibili ad altri client connessi, ad esempio nei giochi in cui gli utenti devono agire sul comportamento di altri client. O se il tuo sito web sta monitorando qualcosa, in cui il server trasmette i dati al cliente tutto il tempo, ad esempio i mercati azionari (dal vivo).

Se non è necessario inviare i dati PUSH dal server, solitamente è più semplice utilizzare un server REST HTTP stateless. HTTP utilizza un modello di comunicazione di richiesta di risposta semplice.

Sto pensando di passare a un’API WebSocket per tutte le funzioni del sito

No. Non dovresti farlo. Non c’è niente di male se supportate entrambi i modelli. Utilizzare REST per comunicazioni / richieste semplici e WebSocket per comunicazioni bidirezionali, in particolare quando il server desidera inviare notifiche in tempo reale.

WebSocket è un protocollo più efficiente rispetto a RESTful HTTP ma ha ancora risultati RESTful HTTP su WebSocket nelle aree sottostanti.

  1. Crea / Aggiorna / Elimina risorse sono state definite bene per HTTP. Devi implementare queste operazioni a basso livello per WebSockets.

  2. Le connessioni WebSocket vengono ridimensionate verticalmente su un singolo server, mentre le connessioni HTTP vengono scalate orizzontalmente. Esistono alcune soluzioni proprietarie non basate su standard per il ridimensionamento orizzontale WebSocket.

  3. HTTP ha molte buone caratteristiche come il caching, il routing, il multiplexing, il gzip, ecc. Questi devono essere costruiti su Websocket se si sceglie Websocket.

  4. Le ottimizzazioni dei motori di ricerca funzionano bene per gli URL HTTP.

  5. Tutti i proxy, DNS, i firewall non sono ancora completamente a conoscenza del traffico WebSocket. Consentono la porta 80 ma potrebbero limitare il traffico effettuando il controllo prima su di esso.

  6. La sicurezza con WebSocket è un approccio tutto o niente.

Dai un’occhiata a questo articolo per maggiori dettagli.

L’unico problema che posso usare TCP (WebSockets) come strategia principale per la consegna di contenuti web è che c’è poco materiale di lettura là fuori su come progettare l’architettura e l’infrastruttura del tuo sito web usando TCP.

Quindi non puoi imparare dagli errori degli altri e lo sviluppo sarà più lento. Non è nemmeno una strategia “provata e testata”.

Naturalmente anche tu perderai tutti i vantaggi di HTTP (Essere senza stato e il caching sono i maggiori vantaggi).

Ricorda che HTTP è un’astrazione per TCP progettata per servire contenuti web.

E non dimentichiamo che i motori di ricerca e SEO non fanno websocket. Quindi puoi dimenticare SEO.

Personalmente raccomanderei contro questo perché c’è troppo rischio.

Non usare WS per servire siti web, usarlo per servire applicazioni web

Tuttavia, se hai un giocattolo o un sito web personale con tutti i mezzi per farlo. Provalo, sii all’avanguardia. Per un’azienda o un’azienda non è ansible giustificare il rischio di fare ciò.

Vorrei prendere in considerazione l’utilizzo di entrambi. Ogni tecnologia ha il suo merito e non esiste una soluzione adatta a tutte le dimensioni.

La separazione del lavoro va in questo modo:

1) WebSockets sarebbe il metodo principale di un’applicazione per comunicare con il server in cui è richiesta una sessione. Questo elimina molti hack necessari per i browser più vecchi (il problema è il supporto per i browser più vecchi che elimineranno questo problema)

2) L’API RESTful viene utilizzata per le chiamate GET che non sono orientate alla sessione (ovvero non richiede l’autenticazione) che beneficiano della memorizzazione nella cache del browser. Un buon esempio di questo sarebbe dati di riferimento per i drop down utilizzati da un’applicazione web. Però. può cambiare un po ‘più spesso di …

3) HTML e Javascript. Questi comprendono l’interfaccia utente dell’applicazione web. Questi in genere beneficiano di essere collocati su un CDN.

4) I servizi Web che utilizzano WSDL sono ancora il modo migliore di comunicare a livello aziendale e interaziendale in quanto forniscono uno standard ben definito per il passaggio di messaggi e dati. In primo luogo dovresti scaricarlo su un dispositivo Datapower per eseguire il proxy sul gestore del servizio web.

Tutto ciò avviene sul protocollo HTTP che fornisce già i socket sicuri tramite SSL.

Tuttavia, per l’applicazione mobile, i websocket non possono riconnettersi a una sessione disconnessa ( come riconnettersi a websocket dopo una connessione chiusa ) e la gestione non è banale. Pertanto, per le app mobili, consiglierei comunque API REST e polling.

Un’altra cosa a cui prestare attenzione quando si utilizza WebSockets vs REST è la scalabilità. Le sessioni WebSocket sono ancora gestite dal server. Le API RESTful, se fatte correttamente, sono stateless (il che significa che non c’è stato del server che deve essere gestito), quindi la scalabilità può crescere orizzontalmente (che è più economica) rispetto a quella verticale.

Voglio aggiornamenti dal server?

  • Sì: Socket.io
  • Senza rest

Gli svantaggi di Socket.io sono:

  • Scalabilità: i WebSocket richiedono connessioni aperte e una configurazione Ops molto diversa su scala web.
  • Learnin: Non ho tempo illimitato per il mio apprendimento. Le cose devono essere fatte!

Userò ancora Socket.io nel mio progetto, ma non per i moduli web di base che REST farà bene.

I trasporti basati su WebSockets (o polling lungo) servono principalmente per la comunicazione (quasi) in tempo reale tra server e client. Sebbene ci siano numerosi scenari in cui sono richiesti questi tipi di trasporto, come chat o qualche tipo di feed in tempo reale o altre cose, non tutte le parti di alcune applicazioni web devono necessariamente essere collegate in modo bidirezionale con il server.

REST è un’architettura basata sulle risorse che è ben compresa e offre i suoi vantaggi rispetto ad altre architetture. WebSockets inclina di più a flussi / feed di dati in tempo reale che richiederebbero di creare una sorta di logica basata su server per stabilire la priorità o differenziare tra risorse e feed (nel caso in cui non si desideri utilizzare REST).

Presumo che alla fine ci saranno più framework centronistici WebSockets come lo socketstream in futuro quando questo trasporto sarebbe più diffuso e meglio compreso / documentato sotto forma di tipo di dati / forma di consegna agnostica. Tuttavia, penso, questo non significa che dovrebbe / dovrebbe sostituire il REST solo perché offre funzionalità che non sono necessariamente richieste in numerosi casi d’uso e scenari.

Non è una buona idea. Lo standard non è ancora finalizzato, il supporto varia a seconda dei browser, ecc. Se vuoi farlo ora finirai per ricorrere al flash o al polling lungo, ecc. In futuro probabilmente non lo farà ancora molto senso, dal momento che il server deve supportare lasciando le connessioni aperte a ogni singolo utente. La maggior parte dei server Web è progettata invece per eccellere nel rispondere rapidamente alle richieste e chiuderle il più rapidamente ansible. Diamine, anche il tuo sistema operativo dovrebbe essere regolato per gestire un numero elevato di connessioni simultanee (ogni connessione utilizza più porte e memoria effimere). Attenersi a REST per quanto più ansible del sito.