Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎

Clase Lunes 18/04/2011 - Web III : REST, estado y navegación

publicado a la‎(s)‎ 18 abr. 2011 16:37 por Javier Fernandes   [ actualizado el 25 abr. 2011 12:27 por gisela decuzzi ]

Esquema Stateful


Retomamos el ejemplo de la búsqueda de libros según lo habíamos dejado la clase pasada.

Diagramamos un poco la interacción entre cliente y servidor. Cómo interactuaban los servlets, jsps. Los parámetros que se enviaban y la forma de "guardar" información entre diferentes request.

Vimos que en el primer esquema, el servlet de búsqueda guardaba la lista resultado en la session del usuario.
En realidad esto ya lo vimos la última clase. Y también que trae aparejados varios problemas de concurrencia. Por ejemplo abriendo varios browsers al mismo tiempo, el resultado de la búsqueda "se pisaba".
También está el hecho de que si cada servlet y cada página mete cosas en las session, muy probablemente:
  • la session pase a ser una bolsa de gatos
  • se incremente la probabilidad de que varios atributos de la session colisionen entre diferentes casos de uso, al usar un mismo nombre.
  • comience a crecer y a aumentar su consumo de memoria.
  • en fin, comportamiento errático.
Este esquema se dice que es stateful, ya que en todo momento la aplicación del lado del servidor contiene el estado asociado a cada usuario.

Lo que llamamos "estado" no es exáctamente el estado global de la aplicación, referido a los objetos de negocio compartidos entre todos los usuarios (lease persistencia del dominio).
En cambio nos referimos al estado conversacional que representa la interacción entre el usuario y el sistema. Justamente, la parte más relacionado con el diseño de interfaces de usuario.

Esquema Stateless

Entonces pasamos al segundo esquema, evitando el uso de la session, y permitiendo que el servlet y el jsp se comuniquen a partir del mismo request que comparten (acuérdense que al hacer un forward, el request todavía no se respondió al browser, con lo cual sigue siendo el mismo en el server).

Para esto entonces modificamos el SearchServlet para que "meta" la lista de libros resultado de la búsqueda dentro del request como attribute, haciendo

    request.setAttribute("libros", resultadoBusqueda);

Y ahora el index.jsp en lugar de obtener la lista de resultados, la obtiene del request mismo.

Ahora sí la aplicación, al responder a ese request, pierde toda noción de estado conversacional. Ya que el request muere.
A este tipo de navegación o aplicación se la llama Stateless.

Model 2

Vimos que aparecía un problema con detalle.jsp que nos permitía ver un libro de la lista de resultado. Porque todavía no estaba refactorizada, y dependía de obtener un elemento específico de la lista de resultado de la session.

Y para resolver este problema, volvemos a la idea de Model 2. Donde se establecía la idea de que cada request que hacemos, sería manejado por un servlet, que actuaría de controller.

Este servlet, debería ubicar el libro específico a detallar.

  • Cómo ?
    • Pidiéndolo a la biblioteca
  • Y Cómo lo pediría ? 
    • con algún tipo de identificador único del objeto que haya pasado al html de respuesta y vuelva al server al clickear.
Entonces acá vimos e DetalleServlet.

Stateful vs Stateless

  • Stateless:
    • Ventajas:
      • Escala fácilmente: clustering & disaster recover
      • No sobrecarga el servidor
      • Ventaja: Rest (ver abajo)
    • Desventajas:
      • Nos fuerza a enviar hacia un lado y otro el estado conversacional (ids)
      • No escala en complejidad de funcionalidad: en cierto punto cuando la aplicación tiene casos de uso bien complejos, la solución de pasar ids no escala
  • Stateful:
    • Ventajas:
      • Evita el trabajo manual de enviar y recibir los parámetros del estado conversacional.
      • Nos acerca más a la idea de tener un modelo de objetos vivo en el servidor.
    • Desventajas:
      • No escala
      • Sobrecarga el servidor.
      • Problemas de desincronismo entre browser & server

REST

Vimos luego el ejemplo de detalle.jsp del proyect "rest".
Específicamente el link de "volver" que nos devuele a la página de búsqueda, peeeeero, con la salvedad de que presenta la misma búsqueda original.
Para esto, obviamente debe mantener el estado conversacional, con lo cual este detalle.jsp debe "renderizar" (generar html) el link ya con los parámetros necesarios para la búsqueda en la URL.

Y acá nos frenamos a analizar la URL.

Vimos que al ser GET y recibir los parámetros como parte de la URL (y como la aplicación es Stateless):
  • Nos permite escribir URLs "a mano", y así interactuar con la aplicación directamente.
  • Nos presenta una URL que tiene un significado único en la aplicación. Con su propio estado conversacional.
  • Esto último, nos permite además, guardarnos la URL ("bookmarkearla") y luego accederla nueva y directamente.
A este tipo de aplicaciones y navegación se llama REST: Representational State Transfer.
 

Esta idea aparece con mucha fuerza en el framework ruby on rails.

Como punto intermedio, vimos que muchas aplicaciones actuales presentan una mezcla entre: funcionalidad REST y funcionalidad NO REST.

Generalmente la funcionalidad REST es más bien de consulta o lectura. Para poder navegar contenido a través de la URL. En cambio se hace dificil e incómodo (sino a veces imposible) implementar funcionalidad de interacción más compleja, como crear un cierto objeto de negocio, etc, a través de REST.
Comments