API Websocket per sostituire l'API REST?

Ho un'applicazione la cui funzione primaria opera in tempo reale, tramite websocket o long polling.

Tuttavia, la maggior parte del sito è scritta in modo RESTful, il che è utile per le 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ò renderebbe più facile per me integrare le funzionalità in tempo reale in tutte le parti del sito. Ciò renderebbe più difficile la creazione di applicazioni o client mobili?

Ho scoperto che alcune persone stanno già facendo cose come questa: SocketStream

Per non dire che le altre risposte qui non hanno merito, fanno dei buoni punti. Ma andrò contro il consenso generale e concorderò con te sul fatto che passare a 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 uno stile più RPC tramite websocket. Questa non è una "app giocattolo" e non sto parlando solo di funzionalità in tempo reale, quindi ho delle prenotazioni. Ma vedo molti vantaggi nell'andare su questa strada e sento che potrebbe rivelarsi una soluzione eccezionale.

Il mio piano è utilizzare DNode , SocketIO e Backbone . Con questi strumenti, i modelli e le raccolte di Backbone possono essere trasferiti da / a client e server semplicemente chiamando funzioni in stile RPC. Non è più necessario gestire gli endpoint REST, serializzare / deserializzare oggetti e così via. Non ho ancora lavorato con socketstream, ma vale la pena provarlo.

Ho ancora molta strada da fare prima di poter affermare definitivamente che questa è una buona soluzione, e sono sicuro che non sia la soluzione migliore per ogni applicazione, ma sono convinto che questa combinazione sarebbe eccezionalmente potente. Ammetto che ci siano alcuni inconvenienti, come la perdita della capacità di memorizzare le risorse nella cache. Ma ho la sensazione che i vantaggi li supereranno.

Sarei interessato a seguire i tuoi progressi esplorando questo tipo di soluzione. Se hai degli esperimenti su GitHub, per favore indicameli. Non ne ho ancora, ma spero di farlo presto.

Di seguito è riportato un elenco di collegamenti da leggere in seguito che ho raccolto. Non posso garantire che valgano tutti la pena, poiché ne ho solo scremati molti. Ma si spera che alcuni aiuteranno.

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

• http://www.danielbaulig.de/socket-ioexpress/

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

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Tutorial sull'utilizzo di Pusher con Backbone.js (utilizzando Rails):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

Crea applicazioni con backbone.js sul client e node.js con express, socket.io, dnode sul server.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Utilizzo di Backbone con DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST e WebSocket sono molto diversi. HTTP è senza stato , quindi il server Web non ha bisogno di sapere nulla e si ottiene la memorizzazione nella cache nel browser Web e nei proxy. Se usi WebSocket, il tuo server sta diventando stateful e devi avere una connessione al client sul server.

Comunicazione richiesta-risposta vs Push

Utilizzare WebSocket solo se è necessario PUSH dati 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 per 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 invia continuamente i dati al client, ad esempio i mercati azionari (live).

Se non è necessario PUSH dei dati dal server, di solito è più semplice utilizzare un server REST HTTP senza stato. HTTP utilizza un semplice modello di comunicazione richiesta-risposta .

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

No. Non dovresti farlo. Non c'è nulla di male se si supportano entrambi i modelli. Usa REST per comunicazioni unidirezionali / richieste semplici e WebSocket per comunicazioni bidirezionali, specialmente quando il server desidera inviare notifiche in tempo reale.

WebSocket è un protocollo più efficiente di RESTful HTTP ma mantiene comunque i punteggi HTTP RESTful su WebSocket nelle aree sottostanti.

1. Le risorse Crea / Aggiorna / Elimina sono state definite bene per HTTP. È necessario implementare queste operazioni a basso livello per WebSocket.

2. Le connessioni WebSocket scalano verticalmente su un singolo server dove le connessioni HTTP scalano orizzontalmente. Esistono alcune soluzioni proprietarie non basate su standard per il ridimensionamento orizzontale di WebSocket.

3. HTTP viene fornito con molte buone caratteristiche come caching, routing, multiplexing, gzipping ecc. Questi devono essere costruiti sopra Websocket se si sceglie Websocket.

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

5. Tutti i proxy, DNS e firewall non sono ancora pienamente consapevoli del traffico WebSocket. Consentono la porta 80 ma potrebbero limitare il traffico curiosando prima su di essa.

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 (WebSocket) come principale strategia di distribuzione dei contenuti web è che c'è pochissimo materiale di lettura su come progettare l'architettura e l'infrastruttura del tuo sito web utilizzando TCP.

Quindi non puoi imparare dagli errori di altre persone e lo sviluppo sarà più lento. Inoltre non è una strategia "provata e testata".

Ovviamente perderai anche tutti i vantaggi di HTTP (essere senza stato e il caching sono i vantaggi maggiori).

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

E non dimentichiamo che SEO e motori di ricerca non fanno websocket. Quindi puoi dimenticarti della SEO.

Personalmente lo consiglierei perché c'è troppo rischio.

Non utilizzare WS per servire siti web, usalo per servire applicazioni web

Tuttavia, se hai un giocattolo o un sito web personale, provaci . Provalo, sii all'avanguardia. Per un'azienda o società non puoi giustificare il rischio di farlo.

Ho imparato una piccola lezione (nel modo più duro). Ho creato un'applicazione molto impegnativa che gira sui servizi cloud Ubuntu AWS EC2 (utilizza potenti GPU) e volevo creare un front-end per osservarne i progressi in tempo reale. Dato che necessitavano di dati in tempo reale, era ovvio che avevo bisogno di websocket per eseguire il push degli aggiornamenti.

È iniziato con una prova di concetto e ha funzionato alla grande. Ma poi, quando volevamo renderlo disponibile al pubblico, dovevamo aggiungere la sessione utente, quindi avevamo bisogno di funzionalità di accesso. E non importa come lo guardi, il websocket deve sapere con quale utente ha a che fare, quindi abbiamo scelto la scorciatoia di usare i websocket per autenticare gli utenti . Sembrava ovvio ed era conveniente.

In realtà abbiamo dovuto passare un po 'di tempo in silenzio per rendere affidabili i collegamenti. Abbiamo iniziato con alcuni tutorial websocket economici, ma abbiamo scoperto che la nostra implementazione non era in grado di riconnettersi automaticamente quando la connessione veniva interrotta. Tutto è migliorato quando siamo passati a socket-io. Socket-io è un must!

Detto questo, ad essere onesti, penso che ci siamo persi alcune fantastiche funzionalità di socket-io.Socket-io ha molto di più da offrire e sono sicuro che, se lo prendi in considerazione nel tuo progetto iniziale, puoi ottenere di più da esso. Al contrario, abbiamo appena sostituito i vecchi websocket con la funzionalità websocket di socket-io, e basta. (niente stanze, niente canali, ...) Una riprogettazione avrebbe potuto rendere tutto più potente. Ma non abbiamo avuto tempo per quello. È qualcosa da ricordare per il nostro prossimo progetto.

Successivamente abbiamo iniziato a memorizzare sempre più dati (cronologia utente, fatture, transazioni, ...). Abbiamo archiviato tutto in un database AWS dynamodb e, ANCORA, abbiamo utilizzato socket-io per comunicare le operazioni CRUD dal front-end al backend. Penso che abbiamo preso una strada sbagliata lì. È stato un errore.

• Perché poco dopo abbiamo scoperto che i servizi cloud di Amazon (AWS) offrono alcuni ottimi strumenti di bilanciamento del carico / scalabilità per le applicazioni RESTful .
• Ora abbiamo l'impressione di dover scrivere molto codice per eseguire le strette di mano delle operazioni CRUD.
• Recentemente abbiamo implementato l'integrazione con Paypal. Siamo riusciti a farlo funzionare. Ma ancora una volta, tutti i tutorial lo fanno con le API RESTful . Abbiamo dovuto riscrivere / ripensare i loro esempi per implementarli con websocket. Abbiamo fatto in modo che funzionasse abbastanza velocemente. Ma sembra che stiamo andando controcorrente.

Detto questo, andremo in diretta la prossima settimana. Siamo arrivati ​​in tempo, funziona tutto. Ed è veloce, ma scalerà?

Considererei l'utilizzo di entrambi . Ogni tecnologia ha il suo merito e non esiste una soluzione valida per tutti.

La separazione del lavoro va in questo modo:

1. WebSocket sarebbe il metodo principale di un'applicazione per comunicare con il server in cui è richiesta una sessione. Questo elimina molti hack che sono necessari per i browser meno recenti (il problema è il supporto per i browser meno recenti che lo eliminano)

2. L'API RESTful viene utilizzata per le chiamate GET che non sono orientate alla sessione (ovvero non è necessaria l'autenticazione) che beneficiano della memorizzazione nella cache del browser. Un buon esempio di ciò sarebbero i dati di riferimento per i menu a discesa utilizzati da un'applicazione web. Però. può cambiare un po 'più spesso di ...

3. HTML e Javascript. Questi comprendono l'interfaccia utente della webapp. Questi in genere trarrebbero vantaggio dall'essere inseriti su un CDN.

4. I servizi Web che utilizzano WSDL sono ancora il modo migliore per la comunicazione a livello aziendale e interaziendale poiché forniscono uno standard ben definito per il passaggio di messaggi e dati. Principalmente lo scaricheresti su un dispositivo Datapower per proxy al gestore del tuo servizio web.

Tutto questo accade sul protocollo HTTP che fornisce già l'uso di socket sicuri tramite SSL.

Per l'applicazione mobile, tuttavia, i websocket non possono riconnettersi a una sessione disconnessa ( come riconnettersi a websocket dopo aver chiuso la connessione ) e la gestione non è banale. Quindi, per le app mobili , consiglierei comunque l' API REST e il polling.

Un'altra cosa a cui prestare attenzione quando si utilizza WebSocket rispetto a REST è la scalabilità . Le sessioni WebSocket sono ancora gestite dal server. Le API RESTful, se eseguite correttamente, sono senza stato (il che significa che non esiste uno stato del server che deve essere gestito), quindi la scalabilità può crescere orizzontalmente (che è più economica) che verticalmente .

Voglio aggiornamenti dal server?

• Sì: Socket.io
• Senza riposo

Gli svantaggi di Socket.io sono:

• Scalabilità: i WebSocket richiedono connessioni aperte e una configurazione operativa molto diversa per la scalabilità web.
• Learnin: non ho tempo illimitato per il mio learningin. 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 WebSocket (o long polling) servono principalmente per la comunicazione (quasi) in tempo reale tra il server e il client. Sebbene vi siano numerosi scenari in cui sono richiesti questi tipi di trasporto, come chat o qualche tipo di feed in tempo reale o altro, non tutte le parti di alcune applicazioni web devono essere necessariamente connesse in modo bidirezionale con il server.

REST è un'architettura basata sulle risorse che è ben compresa e offre i propri vantaggi rispetto ad altre architetture. I WebSocket sono più inclini a flussi / feed di dati in tempo reale, il che richiederebbe la creazione di un qualche tipo di logica basata sul server per dare priorità o distinguere tra risorse e feed (nel caso in cui non si desideri utilizzare REST).

Presumo che alla fine ci sarebbero più framework incentrati su WebSockets in futuro come socketstream in futuro, quando questo trasporto sarà più diffuso e meglio compreso / documentato sotto forma di consegna agnostica del tipo di dati / forma. 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 stato finalizzato, il supporto varia a seconda dei browser, ecc. Se vuoi farlo ora, finirai per dover eseguire il fallback al flash o al polling lungo, ecc. In futuro probabilmente non farà ancora un molto sensato, dal momento che il server deve supportare lasciando le connessioni aperte a ogni singolo utente. La maggior parte dei server Web è invece progettata per eccellere nel rispondere rapidamente alle richieste e nel chiuderle il più rapidamente possibile. Diamine, anche il tuo sistema operativo dovrebbe essere ottimizzato per gestire un numero elevato di connessioni simultanee (ciascuna connessione utilizza più porte e memoria effimere). Continua a usare REST per la maggior parte del sito che puoi.