Estoy diseñando un juego que utiliza websockets para la comunicación en tiempo real de los movimientos del juego y el chat entre los participantes.
También necesito clientes para hacer operaciones de metadatos, como:
Mi pregunta es, ¿debería realizarse esta operación en la conexión websocket ya existente, o debería crear puntos finales de API REST para ellos?
La ventaja de usar websockets es que ya está abierto, por lo que será más rápido y ya tengo la autenticación de usuario.
La ventaja de usar API es que todas estas operaciones son muy naturales para la comunicación de solicitud/respuesta. Quiero decir, si necesito implementarlo en websockets, ese cliente emitirá una solicitud y la respuesta llegará en algún momento en el futuro (tal vez), y tendré que escanear el flujo de mensajes en el socket y asignar cada respuesta a la solicitud correspondiente de forma manual.
¿Algún otro punto que deba tener en cuenta y cuál es su opinión al respecto?
REST, como se describe en la disertación de Roy Fielder, proporciona mucho más que interacciones de solicitud/respuesta. Pero la mayoría de las aplicaciones solo implementan los verbos básicos GET/PUT/POST/DELETE/OPTION HTTP. Conceptualmente, REST no se limita a implementarse a través de HTTP. Por lo tanto, WebSockets se puede usar para implementar un protocolo similar.
Supongo que se da cuenta de que WebSockets es efectivamente una implementación de TCP sobre HTTP. Entonces, en términos de infraestructura de red, hay situaciones en las que los mecanismos de almacenamiento en caché/proxing de REST sobre HTTP son más eficaces.
En mi experiencia con REST sobre HTTP, CORS puede ser un problema si usa múltiples orígenes no relacionados. Depende de su servidor en cuanto a qué tan bien puede manejarlos.