peticiones - rest para dummies
¿Cuál es una forma RESTful de monitorear un recurso REST para cambios? (3)
Encontré este artículo proponiendo un nuevo encabezado HTTP, "When-Modified-After", que esencialmente hace lo mismo: el servidor espera y mantiene la conexión abierta hasta que se modifique el recurso.
Prefiero un enfoque basado en la versión en lugar de un enfoque basado en la marca de tiempo, ya que es menos propenso a las condiciones de carrera y le da un poco más de información sobre lo que está recuperando. ¿Alguna idea de este enfoque?
Si hay un recurso REST que deseo monitorear para cambios o modificaciones de otros clientes, ¿cuál es la mejor forma (y la más RESTANTE) de hacerlo?
Una idea que he tenido al hacerlo es proporcionar recursos específicos que mantendrán la conexión abierta en lugar de regresar inmediatamente si el recurso (aún) no existe. Por ejemplo, dado el recurso:
/game/17/playerToMove
un "GET" en este recurso podría decirme que es el turno de mi oponente para moverme. En lugar de sondear continuamente este recurso para averiguar cuándo es mi turno de mudarme, podría notar el número de movimiento (digamos 5) e intentar recuperar el próximo movimiento:
/game/17/move/5
En un modelo REST "normal", parece que una solicitud GET para esta URL arrojaría un error 404 (no encontrado). Sin embargo, si en cambio, el servidor mantiene la conexión abierta hasta que mi oponente haya jugado su jugada, es decir:
PUT /game/17/move/5
entonces el servidor podría devolver los contenidos que mi oponente PUSO en ese recurso. Esto me proporcionaría los datos que necesito, así como también una especie de notificación de cuándo se movió mi oponente sin requerir un sondeo.
¿Es este tipo de esquema RESTful? ¿O viola algún tipo de principio de REST?
La solución propuesta suena como una encuesta larga , que podría funcionar muy bien.
Solicitaría /game/17/move/5 y el servidor no enviará ningún dato, hasta que se complete el movimiento 5. Si la conexión se interrumpe o si obtiene un tiempo de espera, simplemente vuelva a conectarse hasta que obtenga una respuesta válida.
El beneficio de esto es que es muy rápido: tan pronto como el servidor tenga nuevos datos, el cliente lo obtendrá. También es resistente a las conexiones caídas, y funciona si el cliente se desconecta por un tiempo (se puede solicitar /game/17/move/5 una hora después de haber sido movido y obtener los datos instantáneamente, luego pasar a move/6/ y así en)
El problema con el sondeo largo es que cada "encuesta" ata el hilo de un servidor, lo que rompe rápidamente servidores como Apache (ya que se queda sin hilos de trabajo, por lo que no puede aceptar otras solicitudes). Necesita un servidor web especializado para atender las solicitudes de larga duración. El módulo de Python twisted (un "motor de red basado en eventos") es ideal para esto, pero es más trabajo que las encuestas regulares.
En respuesta a su comentario sobre Jetty / Tomcat, no tengo ninguna experiencia con Java, pero parece que ambos usan un sistema similar de pool-of-worker-threads para Apache, por lo que tendrá el mismo problema. Encontré esta publicación que parece abordar exactamente este problema (para Tomcat)
Sugeriría un 404, si su cliente previsto es un navegador web, ya que mantener la conexión abierta puede bloquear activamente las solicitudes del navegador en el cliente al mismo dominio. Depende del cliente la frecuencia de las encuestas.