estoy tratando de entendertoken-based authentication en estos días, que dice serstateless authentication método. Y conocí el concepto destateless web application.

A continuación hay algunos hilos sobre los que leí:

Use Spring MVC para el desarrollo de aplicaciones web sin estado (ninguna respuesta todavia)Stateless Spring MVCCómo hacer que una aplicación web java sea totalmente apátrida¿Cómo hago que mi aplicación web no tenga estado y sigo haciendo algo útil?

Al principio, me entusiasmó esta idea. Pero cada vez más piensostateless es unpseudo-proposition.

Por ejemplo, supongamos que usamos token almacenado por el cliente para la autenticación, ¿cómo podemos hacer una estadística de los usuarios en línea (supongamos que no hay registro)? ¿Almacenaremos el token en DB? ¿No significa eso que almacenamos información de estado en el servidor? Y aún más, ¿la información de usuario simple como el nombre, la edad, etc. en DB también es algún tipo de información de estado?

Creo que la verdadera pregunta aquí no es hacer que una aplicación web sea apátrida, sinopara que la aplicación web maneje correctamente la información del estado de manera que no ponga en peligro la escalabilidad.

Eso depende de cómo interpretar la palabrastateless:

La aplicación web no tiene estado.O la aplicación web no almacena el estadosí mismo.

Prefiero 2 porque siempre puede haber algunainevitable global state (Citado del comentario de @ deceze a su respuesta). Y no importa si almacenamos información de estado como almacenamiento web HTML 5, o encabezado HTTP, o campos de formulario ocultos, o Cookie, el estado aún existe. Solo que se almacena en otro lugar que no sea el servidor.

¿Me estoy perdiendo algo genial? ¿Alguien podría arrojar algo de luz sobre esto para que pueda aliviarme de esta lucha mental?

AGREGAR 1

Acabo de leer sobre el libroServicios web RESTful porLeonard Richardson. En el capítulo 4, al final de la sección.Statelessness, clasifica el estado enApplication State yResource State. Por lo tanto, la información de usuario simple y los datos que mencioné antes, como imágenes, etc., se pueden clasificar comoResource State. Y quéstateless se refiere a esApplication State. Por lo tanto, no rompe el código de apátridas para almacenarresource state en el servidor

Pero el libro también menciona el escenario dondean application key is used to restrict how many times a user can invoke a web service. Admite que dicha información no se puede almacenar en el lado del cliente. Y tener que almacenarlo en el lado del servidor rompe el código de apátrida e introduce el problema de la afinidad de sesión.Afirma que los apátridas pueden evitar problemas de afinidad de sesión, pero no explica cómo. Realmente no veo cómo los apátridas pueden manejar este escenario. ¿Alguien podría arrojar algo de luz aquí?