restful - rest vs soap
¿Cómo entender "RESTful API no tiene estado"? (1)
En pocas palabras: en las aplicaciones REST, cada solicitud debe contener toda la información necesaria para que el servidor la entienda, en lugar de depender de que el servidor recuerde solicitudes anteriores.
Almacenar el estado de la sesión en el servidor viola la restricción sin estado de la arquitectura REST. Por lo tanto, el estado de la sesión debe ser manejado completamente por el cliente.
Sigue leyendo para más detalles.
El estado de la sesión
Las aplicaciones web tradicionales usan sesiones remotas . En este enfoque, el estado de la aplicación se mantiene completamente en el servidor. Vea la siguiente cita de la dissertation de Roy T. Fielding:
El estilo de sesión remota es una variante de cliente-servidor que intenta minimizar la complejidad o maximizar la reutilización de los componentes del cliente en lugar del componente del servidor. Cada cliente inicia una sesión en el servidor y luego invoca una serie de servicios en el servidor, finalmente saliendo de la sesión. El estado de la aplicación se mantiene completamente en el servidor. [...]
Si bien este enfoque presenta algunas ventajas, reduce la escalabilidad del servidor:
Las ventajas del estilo de sesión remota son que es más fácil mantener centralmente la interfaz en el servidor, lo que reduce la preocupación por las inconsistencias en los clientes implementados cuando se amplía la funcionalidad y mejora la eficiencia si las interacciones hacen uso del contexto de sesión extendida en el servidor. Las desventajas son que reduce la escalabilidad del servidor, debido al estado de la aplicación almacenada, y reduce la visibilidad de las interacciones, ya que un monitor tendría que conocer el estado completo del servidor.
La restricción sin estado
El estilo arquitectónico REST se define en la parte superior de un conjunto de restricciones que incluyen la apatridia del servidor . Según Fielding, la restricción sin estado REST se define de la siguiente manera:
[...] 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 lo tanto, el estado de la sesión se mantiene completamente en el cliente. [...]
Esta restricción induce las propiedades de visibilidad , confiabilidad y escalabilidad :
Se mejora la visibilidad porque un sistema de monitoreo no tiene que mirar más allá de un solo dato de solicitud para determinar la naturaleza completa de la solicitud. Se mejora la confiabilidad porque facilita la tarea de recuperación de fallas parciales. Se mejora la escalabilidad porque no tener que almacenar el estado entre las solicitudes permite que el componente del servidor libere recursos rápidamente y simplifica aún más la implementación porque el servidor no tiene que administrar el uso de los recursos entre las solicitudes.
Autenticacion y autorizacion
Si el cliente solicita recursos protegidos que requieren autenticación, cada solicitud debe contener todos los datos necesarios para autenticarse / autorizarse adecuadamente . Vea esta cita del RFC 7235 :
Se supone que la autenticación HTTP no tiene estado: toda la información necesaria para autenticar una solicitud DEBE proporcionarse en la solicitud, en lugar de depender de que el servidor recuerde solicitudes anteriores.
Y los datos de autenticación deben pertenecer al encabezado de
Authorization
HTTP estándar.
Desde el
RFC 7235
:
El campo de encabezado de
Authorizationpermite que un agente de usuario se autentique con un servidor de origen, generalmente, pero no necesariamente, después de recibir una respuesta401(no autorizada). Su valor consiste en credenciales que contienen la información de autenticación del agente de usuario para el ámbito del recurso que se solicita. [...]
El nombre de este encabezado HTTP es lamentable porque lleva autenticación en lugar de datos de autorización .
Para la autenticación, puede usar el esquema de autenticación HTTP básica , que transmite las credenciales como pares de nombre de usuario y contraseña, codificados con Base64:
Authorization: Basic <credentials>
Si no desea enviar el nombre de usuario y la contraseña en cada solicitud, el nombre de usuario y la contraseña podrían intercambiarse por un token (como JWT ) que se envía en cada solicitud. JWT puede contener el nombre de usuario, una fecha de vencimiento y cualquier otro metadato que pueda ser relevante para su aplicación:
Authorization: Bearer <token>
¿Qué podría estar mal con su servidor?
Una vez que tenga un identificador de sesión, supongo que se está creando una sesión HTTP en algún lugar de su aplicación. Puede estar en su propio código o en el código del marco que está utilizando.
En las aplicaciones Java, debe asegurarse de que no se invoquen los siguientes métodos:
Escuché que la
RESTful API should be stateless. All state info should be kept on client side
RESTful API should be stateless. All state info should be kept on client side
.
Pero cuando estoy emitiendo una llamada ajax desde una página web, noté que siempre se envía una cookie de ID de sesión al servidor.
Con esa ID de sesión, puedo obtener el objeto de sesión en el servidor.
Y así puedo
get/set some state info in the session
.
¿Esto rompe el
code of being stateless
para RESTful API?
AGREGAR 1
(El fondo de mi pregunta es el siguiente).
Intenté implementar una página de inicio de sesión llamando a una API RESTful para validar el nombre de usuario y la contraseña.
Cada vez que el usuario intente visitar una página de mi sitio, un
servlet filter
inicio de sesión verificará la
session
(aquí es donde se
getSession()
) para que ese usuario vea si existe información de inicio de sesión válida.
De lo contrario, el filtro de inicio de sesión redirigirá al usuario a la página de inicio de sesión.
En la página de inicio de sesión, se realiza una llamada ajax a una API RESTful en el servidor con nombre de usuario y contraseña. Depende del resultado de retorno de esa API RESTful, el JavaScript en la página decidirá si permite que el usuario ingrese a mi sitio.
Entonces, en este escenario, tengo que usar
session
.
El código detallado se encuentra aquí: ¿Es esta lógica de inicio de sesión a través del sonido de llamada RESTful?