web-dev-qa-db-fra.com

Comment Socket.io et RESTFul peuvent-ils fonctionner ensemble?

(Je ne connais pas RESTFul, veuillez me corriger si mon concept est erroné)

Dans l'architecture RESTFul, nous mappons chaque action sur une URL. Si je clique sur "publier un article", que ce soit en fait l'URL http://example.com/ Et certaines données action=post&content=blahblah.

Si je veux publier, mais pas actualiser la page Web entière, je peux utiliser XMLHTTPRequest de javascript. Je le poste, puis j'obtiens son contenu et je l'insère dans un div de ma page. Ces actions sont toutes asynchrones.

Alors je sais qu'il y a quelque chose qui s'appelle WebSocket et c'est le wrapper socket.io. Il utilise "message" pour communiquer entre le client et le serveur. Lorsque je clique sur "publier", le client appelle simplement socket.send(data) et attend le client.send(data) du serveur. C'est magique. Mais qu'en est-il de l'URL?

Est-il possible d'utiliser les deux modèles sans me répéter? Dans d'autres Word, chaque action a son URL, et certaines d'entre elles peuvent interagir avec l'utilisateur en temps réel (par socket.io?)

De plus, dois-je faire cela? Dans un programme web très interactif (ex. Jeux), le RESTFul est toujours significatif?

node.jssocket.iorestful-architecture
36
Lai Yu-Hsuan

Vous définissez un gestionnaire pour les actions qui correspondent à REST sur http. POST et GET font généralement référence à la mise à jour et à la requête sur une entité. Il n'y a absolument aucune raison vous ne pouvez pas simplement définir un gestionnaire pour les versions génériques de ces opérations CRUD qui peuvent être utilisées dans les deux contextes. La façon dont je le fais généralement est d'introduire le concept d'une "route" pour le transport en temps réel et de les cartographier aux mêmes gestionnaires 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
38
Josh

J'ai posté ceci sur mon blog récemment:

Conception d'une API CRUD pour WebSockets

Lors de la construction Weld , nous utilisons à la fois REST et WebSockets (Socket.io). Trois observations sur WebSockets:

  1. Étant donné que les WebSockets sont si libres, vous pouvez nommer les événements comme vous le souhaitez, mais il sera finalement impossible de déboguer.
  2. Les WebSockets n'ont pas le formulaire de demande/réponse de HTTP, il est donc parfois difficile de savoir d'où vient ou où va un événement.
  3. Ce serait bien si les WebSockets pouvaient s'intégrer 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 des barres obliques ("/") pour que les événements ressemblent à des chemins de routage.
  • La première chaîne est la cible (~ "Nom d'hôte" s'il s'agissait en fait d'un chemin).
  • La deuxième chaîne est le modèle .
  • La troisième chaîne est le verbe CRUD : c'est-à-dire créer, lire, mettre à jour, supprimer.
34
Tom Söderlund