¿La falta de estados en HTTP hace que el protocolo no sea apto para aplicaciones modernas? [cerrado]

Cambié de PHP a ASP.NET, ahora estoy trabajando con formularios web en una empresa algo grande. Pensé un poco e investigé para respaldar mis impresiones sobre los formularios web ASP.NET y llegué a la conclusión de que Webforms es un intento de hacer que las aplicaciones web sean más fáciles de escribir para aquellos que vinieron del mundo de la "programación de escritorio".

Pero antes de evitar WebForms, decidí analizar las necesidades del software que escribimos y me topé con el problema de mantener los estados de las aplicaciones en la Web.

Entiendo que HTTP es un protocolo sin estado, y ASP.NET trata de simular estados con variables de sesión, campos ocultos y estados de vista, también tengo entendido que todo lo mencionado anteriormente tiene fallas y no son formas perfectas de mantener el estado en mi aplicación, pero también entiendo la necesidad de mantener un estado en mi aplicación.

Lo que plantea las preguntas, ¿es el HTTP realmente adecuado para este tipo de trabajo (hacer aplicaciones que requieren estado)? ¿Las herramientas disponibles actualmente para los desarrolladores web son suficientes? ¿Las nuevas herramientas disponibles con HTML5 son efectivas en el trabajo o son solo soluciones para las limitaciones de HTTP?

Me encanta desarrollar para la web, y estoy mucho más familiarizado con la web que con el escritorio, me he estado preguntando acerca de esta cuestión de la apatridia HTTP durante algún tiempo y quiero entender si me falta algún punto o si ' Estoy justo en mis nociones.

El protocolo puede no tener estado, pero la aplicación que escriba podría mantener cualquier estado :)

HTTP es ciertamente una tecnología más antigua que se ha vuelto bastante omnipresente a medida que la web lo fue. Como resultado, las personas están ampliando esta tecnología para hacer muchas cosas ahora con aplicaciones web modernas donde puede parecer que la apatridia de HTTP es un problema. Por lo tanto, usted ve muchas comodidades como los miradores.

Sin embargo, también es posible codificar aplicaciones web modernas de forma apátrida y esto a menudo se prefiere, el desarrollo web RESTful se basa en esta idea. Muchas API web que forman la base de las aplicaciones web modernas son realmente apátridas y deberían serlo. Es una forma diferente de pensar y diseñar. Sus necesidades pueden variar según lo que esté haciendo.

Muchos protocolos no tienen estado cuando se llega a la capa de protocolo sin procesar. La creación de estado no es el principal obstáculo para el desarrollo web. El obstáculo principal es que HTTP por defecto es sin sesión. Es decir, por defecto, una serie de solicitudes de un navegador a un servidor no están relacionadas entre sí.

Lo solucionamos mediante el uso de cookies para denotar una sesión. El servidor ASP.NET entrega una cookie al navegador, que luego la devuelve en una solicitud posterior. Detrás de escena, ASP.NET busca esa cookie y la conecta a la sesión que ha almacenado en caché (suponiendo que la sesión no haya expirado).

A partir de ahí, otros datos pueden asociarse con la sesión y usarse para crear una experiencia personalizada para cada usuario. Los servidores web y los marcos se han vuelto tan buenos en esto que los clientes ricos se pueden construir sobre el protocolo HTTP. Por ejemplo, los clientes de Twitter usan http para todo, desde recuperar una lista de amigos y tweets, hasta enviar mensajes directos a otros usuarios. (Estoy simplificando un poco, hay un protocolo de transmisión TCP totalmente conectado disponible a través de Twitter, pero en su mayor parte, HTTP es el núcleo de todo.

Hasta cierto punto, HTML ha alcanzado sus límites como una tecnología de visualización adecuada, pero el estándar HTML 5 junto con JavaScript y CSS 3 han permitido crear interfaces de usuario ricas que rivalizan con lo que es posible con clientes nativos. De hecho, HTML 5 ha llegado hasta ahora, es compatible como tecnología nativa para aplicaciones de Windows 8. Con bibliotecas como JQuery para el cliente y NodeJS para el servidor, se puede crear una aplicación que use JavaScript para su lógica en el cliente y el servidor y HTML para la visualización y HTTP puro para las comunicaciones.

Entonces, aunque el argumento en el pasado de que HTML / HTTP ha alcanzado su límite podría haber tenido algún mérito, simplemente ya no es el caso.