Come possono socket.io e riposante lavorare insieme?

Question

(Non ho familiarità a riposare, per favore correggimi se il mio concetto è sbagliato)

Nell'architettura riposante, mappiamo ogni azione su un URL. Se faccio clic su "Pubblica un articolo", che in realtà è URL http://example.com/ e alcuni dati action=post&content=blahblah.

Se voglio pubblicare, ma non aggiornare l'intera pagina Web, posso usare XMLHTTPEQUEST di JavaScript. Lo pubblico e poi ottengo il contenuto e lo inserisco in un div nella mia pagina. Queste azioni sono tutte asincroni.

Allora so che c'è qualcosa chiamato WebSocket Ed è un wrapper socket.io. Usa "Messaggio" per comunicare tra client e server. Quando faccio clic su "Pubblica" il client basta chiamare socket.send(data) E aspetta che il server client.send(data). È magico. Ma che ne dici di URL?

È possibile utilizzare i due modelli entrambi senza ripetermi? In altre parole, ogni azione ha il suo URL e alcuni di essi possono interagire con l'utente in tempi (da Socket.io?)

Inoltre, dovrei farlo? In un programma Web molto interattivo (Ex. Games), il Restful è ancora significativo?

Answer 1

Stai definendo un gestore per le azioni che mappa riposano su HTTP. Pubblica e ottieni generalmente fare riferimento all'aggiornamento e alla query su un'entità. Non c'è assolutamente alcun motivo per cui non puoi semplicemente definire un gestore per versioni generiche di queste operazioni CRUD che possono essere utilizzate in entrambi i contesti. Il modo in cui lo faccio generalmente è introdurre il concetto di "percorso" al trasporto in tempo reale e mappando quelli di ritorno agli stessi gestori di CRUD.

Hai una sessione, puoi imporre lo stesso ACL, ecc.

 +---------------------------------+
 |                                 |
 |      BROWSER                    |
 |                                 |
 +--+--^-------------------+---^---+
    |  |                   |   |
    |  |                   |   |
 +--v--+---+            +--v---+---+
 |         |            |          |
 | HTTP    |            | SOCKET.IO|
 +--+---^--+            +--+---^---+
    |   |                  |   |
 +--v---+------------------v---+---+
 |                                 |
 |        ROUTING/PUBSUB           |
 +-+--^-------+--^-------+--^------+
   |  |       |  |       |  |
 +-v--+--+  +-v--+--+  +-v--+-+
 |       |  |       |  |      |
 | USERS |  | ITEMS |  |ETC   |
 +-------+  +-------+  +------+
     ENTITY CRUD HANDLERS

Answer 2

io pubblicato questo sul mio blog recentemente:

Progettazione di un'API CRUD per WebSockets

Quando si costruisce saldare, stiamo usando sia Rest che WebSocket (Socket.io). Tre osservazioni sui websocket:

1. Poiché WebSockets è così libero, puoi nominare eventi come vuoi, ma alla fine sarà impossibile debug.
2. I websocket non hanno la forma di richiesta/risposta di HTTP, quindi a volte può essere difficile dire da dove proviene un evento o va.
3. Sarebbe bello se i websocket potessero adattarsi alla struttura MVC esistente nell'app, preferibilmente utilizzando gli stessi controller dell'API REST.

La mia soluzione:

• Ho due file di routing sul mio server: Route-rest.js e Routes-Sockets.js
• I miei eventi sembrano questo esempio: "AppServer/user/create".
• Io uso tagli in avanti ("/") Per far sembrare gli eventi come percorsi di routing.
• La prima stringa è il obbiettivo (~ "Nome host" se questo era effettivamente un percorso).
• La seconda stringa è il modello.
• La terza stringa è il Verbo Crud: cioè creare, leggere, aggiornare, eliminare.