it-swarm-eu.dev

API Websocket da sostituire REST API?

Ho un'applicazione la cui funzione principale funziona in tempo reale, tramite socket Web o polling lungo.

Tuttavia, la maggior parte del sito è scritta in modo RESTful, il che è utile per le applicazioni e altri clienti in futuro. Tuttavia, sto pensando di passare a un'API WebSocket per tutte le funzioni del sito, lontano da REST. Ciò mi renderebbe più semplice l'integrazione delle 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 del genere: SocketStream

93
Harry

Per non dire che le altre risposte qui non hanno merito, fanno dei buoni punti. Ma vado contro il consenso generale e sono d'accordo con te sul fatto che passare a siti Web per qualcosa di più delle semplici funzionalità in tempo reale è molto interessante.

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 sento che potrebbe rivelarsi una soluzione eccezionale.

Il mio piano è di usare DNode , SocketIO e Backbone . Con questi strumenti, i miei modelli e raccolte Backbone possono essere passati da/a client e server semplicemente chiamando uno stile RPC di funzioni. Niente più gestione REST endpoint, serializzazione/deserializzazione di oggetti e così via. Non ho ancora lavorato con Socketstream, ma vale la pena dare un'occhiata.

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 sono alcuni svantaggi, come la perdita della capacità di memorizzare nella cache le risorse. Ma ho la sensazione che i vantaggi li supereranno.

Sarei interessato a seguire i tuoi progressi esplorando questo tipo di soluzione. Se hai qualche esperimento su github, ti prego di indicarmi. Non ne ho ancora, ma spero presto.

Di seguito è riportato un elenco di collegamenti da leggere in seguito che ho raccolto. Non posso garantire che valgano tutti la pena, dato che ne ho solo scremati molti. Ma spero che alcuni possano aiutare.


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

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

Tutorial 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.

Utilizzando Backbone con DNode:

89
Tauren

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

Comunicazione richiesta-risposta vs Push

Utilizzare WebSocket solo se è necessario Push dati dal server al client, che il modello di comunicazione non è incluso in HTTP ( solo con soluzioni alternative). Push è utile se gli eventi creati da altri client devono essere disponibili per altri client connessi, ad es. nei giochi in cui gli utenti dovrebbero agire sul comportamento di altri clienti. O se il tuo sito Web sta monitorando qualcosa, in cui il server invia continuamente i dati al client, ad es. mercati azionari (live).

Se non è necessario eseguire il push dei dati dal server, in genere è più semplice utilizzare un HTTP stateless REST. HTTP utilizza un semplice modello di comunicazione Request-Reply .

52
Jonas

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

No. Non dovresti farlo. Non ci sono danni se si supportano entrambi i modelli. Usa [~ # ~] rest [~ # ~] per comunicazioni unidirezionali/richieste semplici e WebSocket per la comunicazione bidirezionale, in particolare quando il server desidera inviare notifiche in tempo reale.

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

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

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

  3. HTTP ha molte buone caratteristiche come cache, routing, multiplexing, gziping ecc. Queste devono basarsi su 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.

36
Ravindra babu

L'unico problema che posso usare TCP (WebSocket) come principale strategia di consegna del contenuto Web è che c'è pochissimo materiale di lettura là fuori su come progettare l'architettura e l'infrastruttura del tuo sito Web utilizzando TCP.

Quindi non puoi imparare dagli errori degli altri e lo sviluppo sarà più lento. Inoltre, non è una strategia "provata e testata".

Ovviamente perderai anche tutti i vantaggi di HTTP (Essere apolidi e memorizzazione nella cache sono i maggiori vantaggi).

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

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

Personalmente raccomanderei contro questo in quanto c'è troppo rischio.

Non usare WS per servire siti Web, usalo per servire applicazioni web

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

10
Raynos

Ho imparato una piccola lezione (nel modo più duro). Ho realizzato un'applicazione per il crunching di numeri che gira su servizi cloud Ubuntu AWS EC2 (utilizza potenti GPU) e volevo creare un front-end solo per vederne i progressi in tempo reale. A causa del fatto che aveva bisogno di dati in tempo reale, era ovvio che avevo bisogno di websocket per inviare gli aggiornamenti.

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

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

Detto questo, a dire il vero, penso ci siamo persi alcune fantastiche funzionalità socket-io. Socket-io ha molto di più da offrire, e sono sicuro che se lo prendi in considerazione nel tuo progetto iniziale, puoi ottenerne di più. 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. Questo è qualcosa da ricordare per il nostro prossimo progetto.

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

  • Perché poco dopo abbiamo scoperto che i servizi cloud di Amazon (AWS) offrono alcuni fantastici strumenti di bilanciamento del carico/ridimensionamento per applicazioni RESTful.
  • Ora abbiamo l'impressione di dover scrivere molto codice per eseguire l'handshake delle operazioni CRUD.
  • Di recente abbiamo implementato l'integrazione con Paypal. Siamo riusciti a farlo funzionare. Ma ancora una volta tutti i tutorial lo stanno facendo con API RESTful. Abbiamo dovuto riscrivere/ripensare i loro esempi per implementarli con i websocket. Dobbiamo farlo funzionare abbastanza velocemente però. Ma sembra che siamo andando contro il flusso.

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

3
bvdb

Vorrei prendere in considerazione l'utilizzo di entrambi . Ogni tecnologia ha il suo merito e non esiste una soluzione unica per tutte le soluzioni.

La separazione del lavoro va in questo modo:

  1. WebSocket sarebbe il metodo principale di un'applicazione per comunicare con il server dove è richiesta una sessione. Ciò elimina molti hack che sono necessari per i browser più vecchi (il problema è il supporto per i browser più vecchi che lo elimineranno)

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

  3. HTML e Javascript. Questi comprendono l'interfaccia utente della webapp. Questi trarrebbero beneficio dall'essere collocati su un CDN.

  4. I servizi Web che utilizzano [~ # ~] wsdl [~ # ~] sono ancora il modo migliore di livello aziendale e comunicazione interaziendale in quanto fornisce uno standard ben definito per il passaggio di messaggi e dati. In primo luogo, lo si scarica su un dispositivo Datapower per eseguire il proxy al gestore del servizio Web.

Tutto ciò accade sul protocollo HTTP che già utilizza socket sicuri tramite SSL.

Tuttavia, per l'applicazione mobile, i websocket non possono riconnettersi a una sessione disconnessa ( Come riconnettersi al websocket dopo una stretta connessione ) e gestirlo non è banale. Quindi per le app mobili , consiglierei comunque di raccomandare REST API e polling.

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

3

Voglio aggiornamenti dal server?

  • Sì: Socket.io
  • Senza riposo

Gli svantaggi di Socket.io sono:

  • Scalabilità: WebSocket richiede connessioni aperte e una configurazione Ops molto diversa per il ridimensionamento 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 andrà bene.

2
Michael Cole

I trasporti basati su WebSocket (o polling lungo) 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 la chat o alcuni tipi di feed in tempo reale o altre cose, non tutte le parti di alcune applicazioni Web devono necessariamente essere collegate in modo bidirezionale al server.

REST è un'architettura basata sulle risorse che è ben compresa e offre i suoi vantaggi rispetto ad altre architetture. WebSocket tende maggiormente a flussi/feed di dati in tempo reale, il che richiederebbe di creare un qualche tipo di logica basata su server per stabilire le priorità o differenziare tra risorse e feed (nel caso in cui non si desideri utilizzare REST).

Presumo che alla fine ci sarebbero più framework incentrati su WebSocket come socketstream in futuro quando questo trasporto sarebbe più diffuso e meglio compreso/documentato sotto forma di tipo di dati/modulo di consegna agnostica. Tuttavia, penso, questo non significa che dovrebbe/dovrebbe sostituire il REST solo perché offre funzionalità che non è necessariamente richiesta in numerosi casi d'uso e scenari.

1
yojimbo87