¿Cómo puedo hacer que mi aplicación web sea sin estado y aún así hacer algo útil?

Question

que he visto este consejo ...

idealmente la web debe seguir el principio descansar y estar completamente sin estado. Por lo tanto, una sola URL debe identificar un solo recurso, sin tener que mantener el historial de navegación de cada usuario.

... y leí la página de Wikipedia http://en.wikipedia.org/wiki/REST y realmente suena bien, pero no entiendo cómo implementarlo realmente. Estoy trabajando en ASP .NET Webforms NOT MVC.

Por ejemplo, en la aplicación que estoy por construir, necesito que mi usuario inicie sesión antes de permitirles hacer algo. Hay un par de aros que deben pasar antes de que se les permita hacer muchas cosas útiles, como Aceptar T y C, y confirmar que sus detalles básicos no se hayan modificado. ¡Finalmente se les permite hacer algo que realmente quieren como BuyAProduct!

Me parece (vengo del mundo HEAVILY stateful del cliente Rich) que necesito estado para registrar lo que han hecho e inferir de eso lo que están autorizados a hacer. No veo cómo puedo apoyarlos (por ejemplo) marcando el URI de BuyAProduct. Cuando llegan al marcador, ¿cómo sé si se han registrado y si han aceptado las T y C y si han verificado diligentemente sus detalles básicos?

Me encanta la idea de que la aplicación sea apátrida, en parte porque parece resolver por completo el problema de "¿Qué diablos hago cuando el usuario hace clic en los botones Atrás y Adelante?" No veo cómo puedo lograr que funcione correctamente. Siento que me estoy perdiendo algo realmente fundamental sobre esto.

Answer 1

El consejo no está sugiriendo que la aplicación sea apátrida, lo que sugiere que los recursos en la aplicación deberían ser apátridas. Es decir, una página llamada "www.misitio.es/resources/123" siempre representará el mismo recurso, independientemente de qué usuario esté accediendo a él o si está conectado o no.

(El hecho de que es posible denegar el acceso de no usuario conectado es un tema aparte - el punto es que el propio Uri no se basa en datos específicos del usuario para trabajar.)

Por ejemplo , el tipo de sitios que violan esta regla son aquellos en los que navega a una página de producto, envíele un correo electrónico a Uri a su amigo, y al hacer clic en él, verá un mensaje en la línea de "Lo siento, su sesión ha expirado" o "Este producto no existe" o similar. La razón por la que esto sucede es porque el URI incluye algo específico para la sesión del usuario en el sitio, y si un usuario diferente intenta usar el enlace (o el mismo usuario en otro momento), ya no es válido.

Por lo tanto, siempre necesitará algún tipo de estado para su aplicación, pero donde se implementa ese estado es el factor importante.

Espero que ayude a arrojar un poco de luz!

Answer 2

Si quieres hacer formularios web, es genial. Si quieres hacer REST eso también es genial. Pero, por favor, por el amor a todo lo sagrado, no intente adherirse a los principios de REST utilizando formularios web.

Para aclarar más este punto, no creo que los formularios web sean una buena elección para REST porque el modelo conceptual en el que se basa WebForms es uno en el que abstrae la Web. Fue construido para emular el modelo de desarrollo de VB.

REST abarca HTTP y la naturaleza distribuida de las aplicaciones web. Los dos enfoques no son compatibles.

Answer 3

Aquí está la cosa: REST se trata de comunicaciones con estado a través de un protocolo sin estado. No es que REST sea apátrida. WebForms le permite retener el estado entre las solicitudes. ¿Por qué es eso necesario? Te permite hacer cosas como ordenar elementos en una lista con los botones arriba/abajo sin tener que actualizar el recurso subyacente con cada clic. No necesitas eso. Simplemente, PONGA la representación de recursos para que se vea correcta o use JavaScript para editar su representación y luego realice una PUT al final una vez que esté satisfecho. (Tenga en cuenta que he usado palabras, se debe publicar. Lo que realmente está haciendo es sustituir la representación por lo que el futuro GET recuperar el estado de derecho .)

Web Forms utiliza el poste para todo. Solo debe enviar a una URL cuando está creando un nuevo elemento y no sabe dónde vivirá. Si conoce su url, entonces debe usar PUT para crear o reemplazar. Si necesita pasos intermedios para, por ejemplo, un carrito de compras, debe crear representaciones de recursos para esos pasos intermedios. Su navegador y servidor se comunican al pasar representaciones completas entre ellos. Es un simple mensaje de respuesta/solicitud que pasa.

WebForms no recomienda esto. Usted puede construir sistemas RESTful en WebForms, pero el modelo predeterminado lo alejará de él hacia un enfoque RPC. Puedo pensar en dos formas: Front Controller (en cuyo caso deberías considerar MVC) o usar archivos .ashx para casi todo. El modelo de Postback borra bastante bien cualquier esperanza real de realizar un REST verdadero con WebForms/.aspx reales (es decir, PUT y DELETE siempre son POST y, por lo tanto, fallan el modelo REST).

Answer 4

Una cookie parece ser la respuesta a su pregunta. Puede usar el proveedor de autenticación .net que configurará una cookie, que su aplicación puede verificar y solicitar su presencia si desean comprar algo.

Lo que desea evitar es mantener una representación del estado de ellos en el servidor, también conocido como cookie de sesión. Eso hará que escalar sea más difícil.

Answer 5

Está bien mantener el estado de los recursos. La "prohibición sin estado" solo se refiere al estado de la sesión.

He aquí un extracto de Roy Fielding's seminal REST derivation:

A continuación añadimos una restricción a la interacción cliente-servidor: comunicación debe ser sin estado en la naturaleza, como en el estilo cliente sin estado-servidor (CSS) de Sección 3.4.3 (Figura 5-3), , de modo que cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud, y no puede aprovechar ventaja de cualquier contexto almacenado en el servidor. El estado de la sesión es por lo tanto, se mantiene completamente en el cliente.