java - repositoryrestresource - Cómo mezclar spring-data-rest con springsocket en una sola implementación
spring data rest custom controller (1)
Me gustaría sincronizar el estado con todos los clientes interesados en cambios de entidades particulares. Entonces me gustaría lograr algo como:
- exponer CRUD API en la entidad (a través de
HTTP/REST
ywebsockets
) - y enrutar la respuesta (de las llamadas modificadoras) al tema
websockets
Así que, técnicamente, me interesarían las ideas para mezclar spring-data-rest con la implementación de spring websockets para lograr algo así como spring-data-websocket.
Me vienen a la mente dos soluciones y, de hecho, ambas serían:
- spring-data-rest para exponer mis entidades a través de
REST/HTTP API
- Controladores de
websocket
(usados para las llamadas de modificación a las entidades)
Los controladores de websocket
verían así:
@Controller
public class EntityAWebSocketController {
@MessageMapping("/EntityA/update")
@SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Escenario 1: Websocket API
llamada desde Websocket API
REST/HTTP API
Reglas:
- la solicitud del cliente siempre es
REST/HTTP API
- la respuesta es
REST/HTTP API
para todas las operaciones - Además, para modificar las operaciones, el mensaje de
websocket
viene
Técnicamente, podría lograrse, por:
- llamando a los controladores
websocket
de los eventos spring-rest-data (concretamente enAfterCreateEvent
,AfterSaveEvent
,AfterLinkSaveEvent
,AfterDeleteEvent
)
Aún así, la solución me parece bastante enfermiza , ya que tendría que buscar:
- cliente A - Solicitud
HTTP
-> Servidor (controlador spring-data-rest) - Servidor (AfterXXXEvent en el controlador spring-data-rest) -
websocket
message -> Springwebsocket
controller - Controlador websocket de primavera - mensaje
websocket
través de tema -> todos los clientes interesados en el tema - Servidor (controlador spring-data-rest) - Respuesta
HTTP
-> cliente A
Escenario 2: Websocket API
independiente de REST API
Reglas:
- la solicitud del cliente es
REST/HTTP API
para operaciones que no modifican - la respuesta es
REST/HTTP API
para operaciones que no modifican - el cliente envía un mensaje de
websocket
para todas las operaciones de modificación -
websocket
mensajewebsocket
se envía al cliente solo para todas las operaciones de modificación
Bueno, si no surgen otras ideas, iré por la última, pero aún así, sería genial si pudiera haber generado de alguna manera métodos C(R)UD
expuestos a través de websockets
, algo así como spring-data-websockets y manejar solo las rutas en mi implementación.
Como me siento como que tendría que exponer manualmente (a través de *WebSocketController
s) todos los métodos CUD
para todas mis entidades. Y podría ser demasiado flojo para eso.
Ideas?
El escenario 2 se refiere, en el último paso, a un solo cliente. Pero pensé que su requisito era un tema, ya que quería varios clientes. Si quería completar 2 para su requerimiento establecido, entonces puede mantener una lista de clientes e implementar su propia cola o utilizar ForkJoinPool para enviar mensajes a todos sus clientes que escuchan en sus WebSockets. Una vez dicho esto, un tema es definitivamente más elegante aquí, pero en general parece demasiado complicado con diferentes interfaces
Para todos los mensajes de cliente a servidor, simplemente vaya con un protocolo simple y use una colección para parametrizar, podría ser RParam1 .......
En el servidor, necesita un controlador para asignarlos a diferentes solicitudes (y operaciones). De alguna manera, no parece demasiado trabajo. Espero que esto ayude.