¿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 habla de 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 al 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 el estado de los recursos, por ejemplo, cualquier almacén de datos, imagen, etc., lo cual podría decirse que es todo el punto de REST.

¿Es justo decir que la mayoría de los intentos de reposo puro (definidos por la presente 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 una sesión es común, en particular para los desarrolladores web, pero ¿es RESTANTE de acuerdo con la definición anterior?

rest

— Mate
fuente

2

De acuerdo con esa definición, diría que prácticamente nada es tranquilo, pero ¿cómo es que esa definición sea razonablemente lógica? Imagine una búsqueda de Google "tranquila", en la que debe proporcionar un índice de Internet en la solicitud de Google para que lo busque. ¿Qué? No, decir que no puede tener una tienda de persistencia y estar tranquilo equivaldría a decir que las interfaces tranquilas no tienen ningún sentido. Eso no significa que todos deberíamos comenzar a mantener sesiones en memoria y decir que sigue siendo un buen diseño de descanso ...

— Jimmy Hoffa

3

Creo que debe tenerse en cuenta que hay una distinción entre el estado de la aplicación y el estado de los recursos (el índice de Google sería el estado de los recursos y es perfectamente legítimo). Debería dejar eso más claro en la pregunta.

— Matt

hay tal distinción? Por favor, defínalo. :) He visto a personas tratar de definir esto antes, pero se vuelve muy confuso porque en realidad no son diferentes. Ambos son datos mutables, la única distinción relevante entre una forma de estado y otra es si es persistente o no, donde la forma no significa que generalmente es regenerable, que es lo que la hace diferente.

— Jimmy Hoffa

1

Me lo he preguntado yo mismo. Dado que nadie ha explicado por qué mi aplicación debería querer una estrella dorada "tranquila", tampoco me preocupa.

— psr

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 tiene una cuenta WSJ. Haga clic, envíe, falle. Claramente, la experiencia de mi hermana en esa URL es diferente a la de su amiga.

Relacionado, pero no estrictamente sobre el tema: estoy en la fase inicial de diseño de una aplicación diseñada para apoyar importantes esfuerzos de investigación en la red (llamados misiones (piense: marcadores en 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 de estado de la interfaz de usuario (por ejemplo, qué visualizaciones de qué datos se muestran en qué paneles) junto con los permisos apropiados 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 acceder al objeto de vista podría considerarse RESTful en el sentido de que todos los que lo poseen obtienen la misma información / experiencia.

— Peter Rowell
fuente

1

Usted es objeto de vista ejemplo es otro punto de vista sobre este tema. Ordenado.

— Matt

Aceptando esto como la respuesta, a pesar de las otras excelentes respuestas, principalmente porque responde la pregunta directamente y da un ejemplo muy claro. Además, la segunda porción en los objetos de vista inclinó la balanza.

— Matt

1

Si está diciendo que el sitio wsj es un ejemplo de una aplicación no tranquila, no estoy de acuerdo con que su ejemplo lo demuestre. Si el sitio WSJ se basa, por ejemplo, en datos proporcionados completamente por el cliente de su hermana para presentarle los datos, entonces es por la definición que dio @Matt, RESTful. Sin embargo, si se basa en un estado de sesión temporal en memoria, es por la definición que Matt no dio RESTful. Simplemente señalo esto porque la definición que Matt dio se basa en detalles de implementación, mientras que REST está mejor definido por la técnica de consumo.

— Jimmy Hoffa

@JimmyHoffa - Mi comprensión de las restricciones de REST es que no tiene estado . Eso me parece bastante inequívoco.

— Peter Rowell

Si la aplicación WSJ no tuviera estado, el cliente debería enviar el artículo visible. Ese artículo puede ser editado en cualquier momento por los administradores del sitio, no se equivoque, es parte del estado de la aplicación WSJ. Creo que la distinción que se está buscando es que es un estado persistente , por lo que tendrá más garantías y menos gastos generales de administración que el estado impersistente, como las sesiones, junto con un control de atomicidad más simple en las transacciones en él. Esto, junto con el modelo de consumo simple, es para lo que la gente quiere descansar. (Creo)

— Jimmy Hoffa

2

¿Las sesiones del lado del servidor violan REST?

Definitivamente lo hacen! Cuando implementa REST, no debe haber una sesión del lado del servidor; de lo contrario, tiene 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 realiza una nueva solicitud. El servidor es libre de almacenar en caché la información para acelerar el servicio de solicitudes posteriores, pero la información almacenada en caché no debe equivaler a una sesión del lado del servidor. En otras palabras, la solicitud en sí misma debe contener suficiente información para ser procesada incluso en ausencia del estado en caché.

— dasblinkenlight
fuente

1

Probablemente depende de lo que quiere 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" de 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": está almacenado en el lado del servidor, limitado en el tiempo y relacionado con un cliente (generalmente sus permisos).

Me sorprendería mucho si este tipo de operación se etiquetara como no RESTful. OAuth es un ejemplo.

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

— Kos
fuente

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 llama 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.

— Puckl
fuente

eso no es necesariamente cierto que los usuarios verán lo mismo. El acceso puede dictar cuánto puede ver cualquier usuario.

— Erik

@Erik Pero el usuario indicaría cuánto desea ver en la solicitud (incluido el uso del encabezado de aceptación), por lo que las respuestas de Puckl son ciertas.

— Johan

1

@Johan Volvería datos diferentes para diferentes usuarios, desde el mismo punto final. De lo contrario, ¿cuál es el punto de autenticar al usuario?

— Erik

@ Erik Yo también haría eso. Sin embargo, creo que la autenticación está fuera del estado del recurso, por lo que, estrictamente hablando, si la vista se ve afectada por el usuario autenticado, ya no es RESTful. Tal vez si quisiera su insignia RESTful debería crear múltiples "vistas" del recurso, dependiendo de quién solicite acceso, autoriza el acceso a solo algunas de las vistas. Por lo tanto, el público puede tener acceso a / userprofiles / {userID} / publicview y el usuario tiene acceso a / userprofiles / {userID} / fullprofile y los amigos autorizados tienen acceso a / userprofiles / {userID} / friendsview

— Johan

0

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

Las sesiones, y en términos más generales, le permiten evitar esto, y esto tiene algunos beneficios positivos en el rendimiento (menos datos transferidos) y 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 aplicaciones RESTful que no usan estado a través de sesiones.

— Oleksi
fuente

Estoy en desacuerdo. Tiene un sitio de compras que le permite filtrar por marca, color y tamaño. Los sitios web tradicionales de Web 1.0 manejarían esto con algunas casillas de verificación, una sesión del lado del servidor y POST. Si quiero compartir el enlace a example.org/shirts, la gente no verá que seleccioné Medium, Black and Roots. (Esto también provoca el feo mensaje "estás rePOSTANDO datos" cuando haces clic hacia atrás). Pero si comparto el enlace a (p. Ej.) Example.org/shirts/medium-black-roots, todos tienen la misma representación. Toda la información de estado necesaria está en la URL (o en el cuerpo POST si es necesario, pero no puede compartirla).

— Jesse Buchanan

... RESTful puede no ser adecuado para todo. ¿Está su aplicación hipotética orientada a los recursos (un sitio de compras ciertamente lo es)? Quizás no sea adecuado para un RIA, con mucho estado, que no está orientado a los recursos. No puedo pensar en ningún buen ejemplo para ser honesto.

— Jesse Buchanan

0

Lo que Fielding quiso decir con esa declaración es que el servidor de aplicaciones que aloja la API REST no asocia el estado ambiente con una solicitud de algún tipo de mecanismo detrás de 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 aplicaciones no debería tener estado . Sin embargo, el servidor de aplicaciones puede delegar solicitudes de estado de recursos al servidor de 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 el encabezado de Autorización o el Uri mismo. Después de todo, REST se basa en el modelo cliente / servidor.

— eulerfx
fuente