Por supuesto, puede almacenar algunos datos de usuario en una base de datos, siempre que dichos datos se conviertan en nuevos recursos (con su identificador de recursos) o parte de un recurso existente, accesible desde la interfaz Uniforme de su API.
Entonces dependerá de su capa de acceso a la base de datos devolver constantemente los datos de este recurso desde cualquier servidor intermedio como para cualquier otro dato de base de datos.
El hecho de que dichos datos estén relacionados con un “Usuario” específico significa que:
- ¿Cuáles son los mejores temas de color para una aplicación web (herramienta de gestión de proyectos)?
- ¿Por qué XMPP no es más popular en el desarrollo web?
- ¿Cuál es el mejor sistema SSO basado en la web?
- ¿Cuál es el mejor software de contabilidad empresarial basado en la web?
- ¿Qué tan relevante es CodeWars en el desarrollo web?
opción 1: dado que REST es impulsado por hipermedia, su interfaz uniforme debe proporcionar una referencia (un enlace) a su identificador de recurso relacionado (por ejemplo, una URL) desde la representación de recursos “Usuario” (JSON, XML, HTML, …).
Opción 2: se convierte en parte del recurso del usuario en sí, y luego forma parte de la representación del usuario. En tal situación, el envío de dichos datos a la base de datos se consideraría, desde el punto de vista de la API REST, como una actualización del recurso “Usuario”.
Lo importante es considerar si:
– dicha vida útil de los datos del usuario está vinculada a la sesión del cliente del usuario o no
– dichos datos de usuario deben ser accesibles desde múltiples clientes o no
Si dicha vida útil de los datos está directamente relacionada con la sesión del cliente Y no es accesible desde múltiples clientes / dispositivos, entonces dichos datos se consideran como un estado de sesión y la regla sin estado requiere que se almacene solo en el lado del cliente.
Tenga en cuenta que desde HTML5, el estado del cliente en la plataforma web también se puede mantener durante la vida útil de la sesión, lo que mejora la capacidad de respuesta de las aplicaciones, siempre que estos datos no sean necesarios para otro cliente.
También puede interesarle esta publicación de blog que describe la diferencia entre “estado de la aplicación” y “estado del recurso”: REST, ¿dónde está mi estado?
