¿Las sesiones del lado del servidor violan REST?

14

Según Roy Fielding (uno de los principales autores de la especificación HTTP) en su tesis seminal Architectural Styles cuando discutir REST , menciona:

  

[E] Cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud y no puede aprovechar ningún contexto almacenado en el servidor.

Por "contexto almacenado" se refiere a estado de la aplicación , por ejemplo. cuál es el número de página para la página siguiente en comparación con estado del recurso , por ejemplo, cualquier almacén de datos, imagen, etc., que es posiblemente el punto entero de REST.

¿Es justo decir que la mayoría de los intentos de pure en reposo (aquí definidos como una implementación que se ajusta a la tesis anterior) deben fallar debido a su dependencia en el almacenamiento de datos de sesión en el servidor (¿persistente o no)?

El concepto de sesión es común, en particular para los desarrolladores web, pero ¿es RESTful según la definición anterior?

    
pregunta Matt 05.10.2012 - 17:54

6 respuestas

10

Yo diría que sí, el estado de la sesión hace que una aplicación RESTful no sea RESTful. Ejemplo trivial, mi hermana se suscribe al Wall Street Journal. Regularmente leerá algo detrás del muro de pago y decidirá enviar un enlace (a través de su propio cliente de correo electrónico, no a través de WSJ) a un amigo que no tenga una cuenta de WSJ. Haga clic, enviar, fallar. Claramente, la experiencia de mi hermana en esa URL es diferente a la de su amiga.

Relacionado, pero no estrictamente relacionado con el tema: estoy en la fase inicial de diseño de una aplicación diseñada para respaldar importantes esfuerzos de investigación en la red (llamadas misiones (piense : marcadores en los esteroides y LSD)). El propietario de la búsqueda desea compartir una vista particular de sus datos con otra persona, pero esta vista requiere una combinación del estado de la interfaz de usuario (por ejemplo, qué visualizaciones de qué datos se muestran en qué paneles) junto con los permisos adecuados para acceder a la interfaz de usuario y los datos mostrados. Se requiere una gran cantidad de estado almacenado para que el destinatario obtenga la vista deseada.

Mi solución actual es almacenar toda la UI / ACL / cualquier información necesaria para la vista en un objeto separado y devolver la URL (probablemente un UUID) para ese objeto. Creo que el acceso al objeto de vista podría considerarse RESTO en el sentido de que todos los que lo posean obtienen la misma información / experiencia.

    
respondido por el Peter Rowell 05.10.2012 - 18:30
2
  

¿Las sesiones del lado del servidor violan REST?

Definitivamente lo hacen! Cuando implementas REST, no debe haber una sesión del lado del servidor, de lo contrario tienes una solución RPC / REST híbrida.

El cliente debe enviar a un servicio RESTful todo el contexto necesario para atender la solicitud, incluida la información necesaria para autenticar al cliente, cada vez que se realice una nueva solicitud. El servidor tiene la libertad de almacenar en caché la información para que el servicio de solicitudes posteriores sea más rápido, pero la información almacenada en caché no debe constituir una sesión del lado del servidor. En otras palabras, la solicitud en sí debe contener suficiente información para ser procesada incluso en ausencia del estado almacenado en caché.

    
respondido por el dasblinkenlight 05.10.2012 - 19:05
1

Probablemente depende de lo que quieres decir con "datos de sesión". ¿Es ese un término preciso?

La comunicación segura entre dos partes a menudo implica que el servidor genere (y almacene) un "token de acceso" por tiempo limitado que el cliente debe suministrar con cada solicitud como una forma de autorización. Este token de acceso ya es lo que yo llamaría "datos de sesión": se almacena en el servidor, tiene un límite de tiempo y está relacionado con un cliente (generalmente sus permisos).

Me sorprendería mucho si este tipo de operación fuera etiquetada como no REST. OAuth es un ejemplo.

No soy un especialista y no tengo mucha confianza aquí; Solo comparto mis ideas con la esperanza de que sean útiles.

    
respondido por el Kos 05.10.2012 - 18:08
1

El punto más importante de REST es que un URI a un recurso siempre apunta al mismo recurso. Para que los usuarios puedan pasar una referencia a este recurso y todos vean lo mismo. Esto se denomina transferencia de estado representacional (REST). Si el servidor mantiene el estado y entrega un recurso diferente para el mismo URI, diría que esto ya no es REST puro.

    
respondido por el Puckl 05.10.2012 - 18:48
0

Las sesiones se utilizan básicamente para agregar el estado a las aplicaciones sin estado, RESTful. Así que formalmente, esto hace que su aplicación RESTful tenga un estado estable, sin embargo, mantener el estado del servidor hace que su vida sea un poco más fácil, ya que no tiene que pasar todos los datos en cada solicitud / respuesta.

Las sesiones, y en general el estado, le permiten evitar esto, y esto tiene algunos beneficios positivos en el rendimiento (menos transferencia de datos) y la seguridad (menos datos disponibles para manipular).

Entonces, si bien viola oficialmente parte de la definición de REST, es tan útil que es raro ver que las aplicaciones REST que no usan el estado a través de las sesiones.

    
respondido por el Oleksi 05.10.2012 - 18:06
0

Lo que Fielding quiere decir con esa declaración es que el servidor de aplicaciones que aloja la API REST no asocia el estado del ambiente con una solicitud de algún tipo de mecanismo detrás de la escena. Considere la diferencia entre un servidor de aplicaciones y un servidor de bases de datos . La restricción REST es que el servidor de la aplicación debe estar sin estado . Sin embargo, el servidor de aplicaciones puede delegar solicitudes para el estado de los recursos en el servidor de la base de datos en función de la información que forma parte de la solicitud, como una combinación de usuario / contraseña en Encabezado de autorización o el propio Uri. Después de todo, REST se basa en el modelo cliente / servidor.

    
respondido por el eulerfx 05.10.2012 - 20:04

Lea otras preguntas en las etiquetas