¿Cómo pueden trabajar Socket.io y Restful juntos?

Question

(No estoy familiarizado con Retful, por favor corríjeme si mi concepto está mal)

En arquitectura RESTful, asignamos cada acción a una URL. Si hago clic en "publicar un artículo", que en realidad sea URL http://example.com/ y algunos datos action=post&content=blahblah.

Si quiero publicar, pero no actualizar toda la página web, puedo usar XMLHTTPRequest de JavaScript. Lo publico y luego obtengo su contenido e inserto en un div en mi página. Esta acción es todas asincrónicas.

Entonces sé que hay algo llamado WebSocket y es envoltura socket.io. Utiliza "mensaje" para comunicarse entre el cliente y el servidor. Cuando hago clic en "publicar" el cliente simplemente llame socket.send(data) y espera el servidor client.send(data). Es mágico. ¿Pero qué tal URL?

¿Es posible usar el modelo dos sin repetirme? En otra palabra, cada acción tiene su URL, y algunos de ellos pueden interactuar con el usuario de verdad (¿por Socket.io?)

Además, ¿debería hacer esto? En un programa web muy interactivo (ex. Juegos), ¿el RESTFUL sigue siendo significativo?

Answer 1

Estás definiendo un controlador para acciones que mapeen para descansar sobre HTTP. Publique y obtenga generalmente consulte la actualización y la consulta sobre una entidad. No hay absolutamente ninguna razón por la que no pueda definir un controlador para versiones genéricas de estas operaciones CRUD que se pueden usar en ambos contextos. La forma en que generalmente hago esto es introducir el concepto de una 'ruta' al transporte en tiempo real y mapearlos de regreso a los mismos manejadores de crud.

Tienes una sesión, puedes imponer el mismo ACL, etc.

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

Answer 2

yo Publicado esto en mi blog recientemente:

Diseño de una API CRUD para WebSockets

Al construir Soldar, estamos utilizando tanto REST y WebSockets (Socket.io). Tres observaciones en WebSockets:

1. Dado que WebSockets son tan gratuitos, puede nombrar eventos cómo desea, pero eventualmente será imposible depurar.
2. WebSockets no tiene el formulario de solicitud/respuesta de HTTP, por lo que a veces puede ser difícil saber de dónde viene un evento o va.
3. Sería bueno si los WebSockets pudieran caber en la estructura MVC existente en la aplicación, preferiblemente usando los mismos controladores que la API REST.

Mi solución:

• Tengo dos archivos de enrutamiento en mi servidor: rutas-rest.js y rutas-colmena.js
• Mis eventos se ven como este ejemplo: "AppServer/user/create".
• yo suelo barras delantera ("/") Para que los eventos parezcan rutas de enrutamiento.
• La primera cadena es la objetivo (~ "Nombre de host" si esto realmente fuera un camino).
• La segunda cadena es la modelo.
• La tercera cadena es la Verbo crud: es decir, crear, leer, actualizar, eliminar.