¿Las sesiones del lado del servidor violan REST?

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.

  

¿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é.

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.

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.

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.

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.