A falta de estados no HTTP torna o protocolo inadequado para aplicativos modernos? [fechadas]

Mudei de PHP para ASP.NET, agora estou trabalhando com webforms em uma empresa um tanto grande. No entanto, pesquisei e pesquisei para apoiar minhas impressões nos formulários da Web do ASP.NET e cheguei à conclusão de que os Webforms são uma tentativa de facilitar a gravação de aplicativos da Web para aqueles que vieram do mundo da "programação de desktop".

Porém, antes de ignorar o WebForms, decidi analisar as necessidades do software que escrevemos e deparamos com a questão de manter os estados de aplicativos na Web.

Entendo que o HTTP é um protocolo sem estado e o ASP.NET tenta simular estados com variáveis ​​de sessão, campos ocultos e estados de exibição. Entendo também que todos os itens acima citados apresentam falhas e não são maneiras perfeitas de manter o estado em meu estado. aplicativo, mas também entendo a necessidade de manter um estado no meu aplicativo.

O que levanta as questões: o HTTP é realmente adequado para esse tipo de trabalho (criação de aplicativos que exigem estado)? As ferramentas atualmente disponíveis para desenvolvedores da Web são suficientes? As novas ferramentas disponíveis com HTML5 são eficazes no trabalho ou são apenas soluções alternativas para as limitações ao HTTP.

Adoro desenvolver para a web e estou muito mais familiarizado com a web do que com a área de trabalho. Estou pensando sobre esse assunto de apatridia HTTP há algum tempo e quero entender se estou perdendo algum ponto ou se estou ' Estou certo em minhas noções.

O protocolo pode ser sem estado, mas o aplicativo que você escreve pode manter qualquer estado :)

O HTTP é certamente uma tecnologia mais antiga que se tornou bastante onipresente à medida que a Web o tornou. Como resultado, as pessoas estão estendendo essa tecnologia para fazer muitas coisas agora com aplicativos da Web modernos, onde pode parecer que a falta de estado do HTTP é um problema. Portanto, você vê muitas conveniências, como os estados de exibição.

No entanto, também é possível codificar aplicativos da web modernos de maneira sem estado e isso geralmente é preferido; o desenvolvimento da web RESTful é baseado nessa idéia. Muitas APIs da Web que formam a base para aplicativos da Web modernos são realmente sem estado e deveriam ser. É uma maneira diferente de pensar e arquitetar. Suas necessidades podem variar dependendo do que você está fazendo.

Muitos protocolos são sem estado quando você desce para a camada de protocolo bruto. Statefulness não é o principal obstáculo ao desenvolvimento da Web. O principal obstáculo é que o HTTP, por padrão, é sem sessão. Ou seja, por padrão, uma série de solicitações de um navegador para um servidor não está relacionada entre si.

Contornamos isso usando cookies para indicar uma sessão. O servidor ASP.NET fornece um cookie ao navegador, que o retorna na solicitação subsequente. Nos bastidores, o ASP.NET procura esse cookie e o conecta à Sessão em cache (supondo que a sessão não tenha atingido o tempo limite).

A partir daí, outros dados podem ser associados à sessão e usados ​​para criar uma experiência personalizada para cada usuário. Servidores da Web e estruturas tornaram-se tão bons nisso que clientes avançados podem ser construídos sobre o protocolo HTTP. Nesse caso, os clientes do Twitter usam http para tudo, desde recuperar uma lista de amigos e tweets até enviar mensagens diretas para outros usuários. (Estou simplificando um pouco, há um protocolo de streaming TCP totalmente conectado disponível através do twitter, mas, na maioria das vezes, o HTTP está no centro de tudo.

Até certo ponto, o HTML atingiu seus limites como uma tecnologia de exibição adequada, mas o padrão HTML 5, juntamente com JavaScript e CSS 3, possibilitou a criação de UIs ricas que rivalizam com o que é possível com clientes nativos. De fato, o HTML 5 chegou até agora, é suportado como uma tecnologia nativa para aplicativos do Windows 8. Com bibliotecas como JQuery para o cliente e NodeJS para o servidor, é possível criar um aplicativo que usa JavaScript para sua lógica no cliente e servidor e HTML para a exibição e HTTP puro para comunicações.

Portanto, embora o argumento no passado de que o HTML / HTTP tenha atingido seu limite possa ter algum mérito, simplesmente não é mais o caso.