Comment le travail Socket.io et RESTFul ensemble?

Question

(je ne suis pas familier RESTFul, s'il vous plaît me corriger si mon concept est erroné)

Dans l'architecture RESTFul, nous la carte toutes les actions à une URL. Si je clique sur « poster un article », il est peut effectivement URL http://example.com/ et certains action=post&content=blahblah de données.

Si je veux poster, mais pas rafraîchir la page Web entière, je peux utiliser XMLHttpRequest de javascript. Je posterai puis obtenir le contenu de et l'insérer dans un div dans ma page. Ces actions est tout asynchrone.

Alors je sais qu'il ya quelque chose appelé WebSocket et de socket.io d'emballage. Il utilise « message » pour communiquer entre le client et le serveur. Lorsque je clique sur « post » le client il suffit d'appeler socket.send(data) et attendez client.send(data) du serveur. Il est magique. Mais que diriez-vous URL?

Il est possible d'utiliser le modèle deux fois sans me répéter? En d'autres termes, chaque action a son URL, et certains d'entre eux peuvent interagir avec l'utilisateur réel en temps opportun (par socket.io?)

De plus, dois-je faire cela? Dans un programme web très interactif (jeux ex.), Le RESTFul est encore un sens?

Answer 1

Vous définissez un gestionnaire d'actions qui correspondent à REST sur http. POST et GET se réfèrent généralement à la mise à jour et d'interrogation sur une entité. Il n'y a absolument aucune raison que vous ne pouvez pas définir simplement un gestionnaire pour les versions génériques de ces opérations CRUD qui peuvent être utilisés dans les deux contextes. La façon dont je fais généralement c'est en introduisant le concept d'une « route » pour le transport en temps réel, et la cartographie ceux qui reviennent aux gestionnaires même CRUD.

Vous avez une session, vous pouvez imposer la même ACL, etc.

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

Answer 2

a publié ce billet sur mon blog récemment:

Conception d'une API CRUD pour WebSockets

Weld , nous utilisons deux REST et WebSockets (Socket.io). Trois observations sur WebSockets:

1. Depuis WebSockets sont si forme libre, vous pouvez nommer les événements comment vous voulez, mais il sera finalement impossible de débogage.
2. WebSockets n'ont pas le formulaire de demande / réponse HTTP si parfois il peut être difficile de dire où un événement vient ou va.
3. Ce serait bien si les WebSockets pourraient entrer dans la structure MVC existante dans l'application, en utilisant de préférence les mêmes contrôleurs que l'API REST.

Ma solution:

• J'ai deux fichiers de routage sur mon serveur: Routes-rest.js et routes-sockets.js
• Mes événements ressemblent à cet exemple: "AppServer/user/create"
.
• J'utilise barres obliques ( « / ») pour faire ressembler les événements comme les chemins de routage.
• La première chaîne est la cible (~ » nom d'hôte » si cela était en fait un chemin).
• La deuxième chaîne est le modèle .
• La troisième chaîne est le CRUD verbe :. À savoir créer, lire, mettre à jour, supprimer