Entendendo a Internet sem estado [fechado]

Estou passando de desenvolvedor de desktop para desenvolvedor web e estou tendo problemas para entender por que o HTTP não tem estado. Quais são as razões para isso? Quais são algumas maneiras pelas quais um desenvolvedor de desktop como eu pode fazer a transição para um ambiente de desenvolvimento sem estado?

Esta é a melhor explicação da internet sem estado que eu já vi:

Como expliquei o REST  para minha esposa
http://www.looah.com/source/view/2284

Esposa: Quem é Roy Fielding?

Ryan: Um cara. Ele é esperto.

Esposa: Ah? O que ele fez?

Ryan: Ele ajudou a escrever os primeiros servidores da Web e, em seguida, fez uma tonelada de pesquisas explicando por que a Web funciona da maneira que funciona. O nome dele está na especificação do protocolo usado para obter páginas dos servidores para o seu navegador.

Esposa: Como isso funciona?

Ryan: A web?

Esposa: Sim.

Ryan: Hmm. Bem, é tudo realmente incrível. E o engraçado é que tudo está muito desvalorizado. O protocolo que eu estava falando, HTTP, é capaz de todo tipo de coisas legais que as pessoas ignoram por algum motivo.

Esposa: Você quer dizer http como o começo do que digito no navegador?

Ryan: Sim. Essa primeira parte informa ao navegador qual protocolo usar. O material digitado por você é um dos avanços mais importantes da história da computação.

Esposa: Por quê?

Ryan: Porque é capaz de descrever a localização de algo em qualquer lugar do mundo e em qualquer lugar do mundo. É a base da web. Você pode pensar nisso como coordenadas GPS para conhecimento e informação.

Esposa: Para páginas da web?

Ryan: Para qualquer coisa realmente. Aquele cara, Roy Fielding, fala muito sobre o que essas coisas apontam na pesquisa sobre a qual eu estava falando. A web é construída em um estilo arquitetural chamado REST. O REST fornece uma definição de recurso, que é o que essas coisas apontam.

Esposa: Uma página da web é um recurso?

Ryan: Mais ou menos . Uma página da web é uma representação de um recurso. Recursos são apenas conceitos. URLs - as coisas que você digita no navegador ...

Esposa: Eu sei o que é um URL ..

Ryan: Ah, certo. Aqueles dizem ao navegador que há um conceito em algum lugar. Um navegador pode pedir uma representação específica do conceito. Especificamente, o navegador solicita a representação do conceito na página da web.

Esposa: Que outros tipos de representações existem?

Ryan: Na verdade, representações é uma dessas coisas que não se acostuma muito. Na maioria dos casos, um recurso possui apenas uma única representação. Mas esperamos que as representações sejam usadas mais no futuro, porque há um monte de novos formatos aparecendo em todo o lugar.

Esposa: Como o que?

Ryan: Hmm. Bem, existe esse conceito que as pessoas estão chamando de Web Services. Isso significa muitas coisas diferentes para muitas pessoas diferentes, mas o conceito básico é que as máquinas podem usar a Web da mesma forma que as pessoas.

Esposa: Isso é outra coisa de robô?

Ryan: Não, na verdade não. Não quero dizer que as máquinas estejam sentadas à mesa e navegando na web. Mas os computadores podem usar esses mesmos protocolos para enviar mensagens um para o outro. Fazemos isso há muito tempo, mas nenhuma das técnicas que usamos hoje funciona bem quando você precisa conversar com todas as máquinas do mundo inteiro.

Esposa: Por que não?

Ryan: Porque eles não foram projetados para serem usados ​​assim. Quando Fielding e seus amigos começaram a construir a web, poder conversar com qualquer máquina em qualquer lugar do mundo era uma preocupação primordial. A maioria das técnicas que usamos no trabalho para fazer com que os computadores conversem entre si não tinha esses requisitos. Você só precisava conversar com um pequeno grupo de máquinas.

Esposa: E agora você precisa conversar com todas as máquinas?

Ryan: Sim - e mais. Precisamos poder conversar com todas as máquinas sobre todas as coisas que estão em todas as outras máquinas. Portanto, precisamos de uma maneira de ter uma máquina informando a outra máquina sobre um recurso que pode estar em outra máquina.

Esposa: O que?

Ryan: Digamos que você esteja conversando com sua irmã e ela quer emprestar a vassoura ou algo assim. Mas você não tem - sua mãe tem. Então você diz à sua irmã para obtê-lo da sua mãe. Isso acontece o tempo todo na vida real e o tempo todo quando as máquinas começam a falar também.

Esposa: Então, como as máquinas se dizem onde estão as coisas?

Ryan: A URL, é claro. Se tudo o que as máquinas precisam falar tiver um URL correspondente, você criou a máquina equivalente a um substantivo. Que você e eu e o resto do mundo concordamos em falar sobre substantivos de uma certa maneira é muito importante, não é?

Esposa: Sim.

Ryan: Máquinas não têm um substantivo universal - é por isso que elas são péssimas. Toda linguagem de programação, banco de dados ou outro tipo de sistema tem uma maneira diferente de falar sobre substantivos. É por isso que o URL é tão importante. Vamos fazer com que todos esses sistemas se digam sobre os nomes um do outro.

Esposa: Mas quando estou vendo uma página da web, não penso assim.

Ryan: Ninguém faz. Exceto Fielding e um punhado de outras pessoas. É por isso que as máquinas ainda são péssimas.

Esposa: E os verbos, pronomes e adjetivos?

Ryan: Engraçado você perguntar, porque esse é outro grande aspecto do REST. Bem, os verbos são assim mesmo.

Esposa: Eu estava apenas brincando.

Ryan: Foi uma piada engraçada, mas na verdade não é uma piada. Os verbos são importantes. Existe um conceito poderoso em programação e teoria da CS chamado polimorfismo. Essa é uma maneira nerd de dizer que substantivos diferentes podem ter o mesmo verbo aplicado a eles.

Esposa: Eu não entendi.

Ryan: Bem ... Olhe para a mesa de café. Quais são os substantivos? Xícara, bandeja, jornal, controle remoto. Agora, o que você pode fazer com todas essas coisas?

Esposa: Eu não entendo ...

Ryan: Você pode pegá-los, certo? Você pode buscá-los. Você pode derrubá-los. Você pode queimá-los. Você pode aplicar esses mesmos verbos exatos a qualquer um dos objetos ali.

Esposa: Ok ... então?

Ryan: Bem, isso é importante. E se, em vez de eu poder dizer para você, "pegue a xícara" e "pegue o jornal" e "pegue o controle remoto"; e se, em vez disso, precisássemos apresentar verbos diferentes para cada um dos substantivos? Eu não conseguia usar a palavra "obter" universalmente, mas precisava criar uma nova palavra para cada combinação de verbo / substantivo.

Esposa: Uau! Isso é estranho.

Ryan: Sim, é. De certa forma, nossos cérebros são inteligentes o suficiente para saber que os mesmos verbos podem ser aplicados a muitos substantivos diferentes. Alguns verbos são mais específicos que outros e se aplicam apenas a um pequeno conjunto de substantivos. Por exemplo, não posso dirigir um copo e não posso beber um carro. Mas alguns verbos são quase universais como GET, PUT e DELETE.

Esposa: Você não pode EXCLUIR uma xícara.

Ryan: Bem, ok, mas você pode jogar fora. Essa foi outra piada, certo?

Esposa: Sim.

Ryan: Enfim, HTTP - este protocolo que Fielding e seus amigos criaram - é sobre aplicar verbos a substantivos. Por exemplo, quando você acessa uma página da web, o navegador faz um HTTP GET no URL digitado e volta uma página da web.

As páginas da Web geralmente têm imagens, certo? Esses são recursos separados. A página da web apenas especifica os URLs das imagens e o navegador acessa e realiza mais GETs HTTP nelas até que todos os recursos sejam obtidos e a página da web seja exibida. Mas o importante aqui é que tipos muito diferentes de substantivos podem ser tratados da mesma forma. Se o substantivo é uma imagem, texto, vídeo, um mp3, uma apresentação de slides, qualquer que seja. Posso obter todas essas coisas da mesma maneira, considerando um URL.

Esposa: Parece que GET é um verbo muito importante.

Ryan: Sim . Especialmente quando você está usando um navegador da Web, porque os navegadores praticamente apenas GET coisas. Eles não fazem muitos outros tipos de interação com os recursos. Isso é um problema porque levou muitas pessoas a supor que o HTTP é apenas para GETing. Mas o HTTP é realmente um protocolo de propósito geral para a aplicação de verbos aos substantivos.

Esposa: Legal. Mas ainda não vejo como isso muda alguma coisa. Que tipos de substantivos e verbos você deseja?

Ryan: Bem, os substantivos estão lá, mas não no formato certo.

Pense em quando você estiver navegando pela amazon.com procurando coisas para me comprar no Natal. Imagine cada um dos produtos como substantivos. Agora, se eles estivessem disponíveis em uma representação que uma máquina pudesse entender, você poderia fazer muitas coisas legais.

Esposa: Por que uma máquina não consegue entender uma página da web normal?

Ryan: Porque as páginas da web são projetadas para serem entendidas pelas pessoas. Uma máquina não se importa com layout e estilo. Máquinas basicamente só precisam dos dados. Idealmente, cada URL teria uma representação legível por humanos e uma legível por máquina. Quando uma máquina obtém o recurso, solicita a legível da máquina. Quando um navegador obtém um recurso para um humano, ele solicita o legível por humanos.

Esposa: Então as pessoas teriam que criar formatos de máquina para todas as suas páginas?

Ryan: Se fosse valioso.

Olha, nós conversamos sobre isso com muita abstração. Que tal dar um exemplo real. Você é professor - na escola, aposto que você tem um grande sistema de computador, ou três ou quatro sistemas de computador mais propensos a permitir que você gerencie os alunos: em quais aulas eles estão, que notas estão recebendo, contatos de emergência, informações sobre os livros dos quais você ensina etc. Se os sistemas são baseados na Web, provavelmente existe uma URL para cada um dos substantivos envolvidos aqui: aluno, professor, turma, livro, sala, etc. Agora, obtendo a URL através o navegador fornece uma página da web. Se houvesse uma representação legível por máquina para cada URL, seria trivial trancar novas ferramentas no sistema, porque todas essas informações seriam consumíveis de maneira padrão. Isso também tornaria um pouco mais fácil para cada um dos sistemas conversar entre si. Ou você pode criar um sistema estadual ou nacional que pudesse conversar com cada um dos sistemas escolares individuais para coletar as notas dos testes. As possibilidades são infinitas.

Cada um dos sistemas obteria informações um do outro usando um simples HTTP GET. Se um sistema precisar adicionar algo a outro sistema, ele usaria um POST HTTP. Se um sistema deseja atualizar algo em outro sistema, ele usa um HTTP PUT. A única coisa que resta descobrir é como devem ser os dados.

Esposa: Então é nisso que você e todas as pessoas do computador estão trabalhando agora? Decidir como devem ser os dados?

Ryan: Infelizmente, não. Em vez disso, a grande maioria está ocupada escrevendo camadas de especificações complexas para fazer essas coisas de uma maneira diferente que não é tão útil ou eloqüente. Substantivos não são universais e verbos não são polimórficos. Estamos jogando décadas de uso real em campo e técnica comprovada e começando de novo com algo que se parece muito com outros sistemas que falharam no passado. Estamos usando HTTP, mas apenas porque isso nos ajuda a conversar com nossas pessoas de rede e segurança menos. Estamos trocando simplicidade por ferramentas e assistentes chamativos.

Esposa: Por quê?

Ryan: Eu não tenho ideia.

Esposa: Por que você não diz alguma coisa?

Ryan: Talvez eu vá.

Como você acha que seria possível armazenar o estado de bilhões de bilhões de bilhões de conexões de bilhões? :) Portanto, você armazena apenas o estado onde necessário, em sessões.

BTW: HTTP não está sem conexão.

Como desenvolvedor de desktop, você pode se sentir mais confortável com experiências ricas da interface do usuário. Mudar para a Web pode parecer um passo atrás. No mundo da web, há menos liberdade de criatividade e isso pode lhe dar uma sensação de restrição. Não deixe que isso te decepcione! Existem várias coisas por aí que podem ajudá-lo a fazer a transição e aqui está uma pequena lista delas:

1. O estado pode ser compartilhado, mas é freqüentemente mantido no servidor e referenciado usando tokens, como IDs de sessão, parâmetros de URL, campos ocultos ou valores de cookies.
2. Modelos sem estado são adequados para o processamento de transações. Tente criar seu modelo de forma a reduzir a quantidade de estado necessária. Os princípios ACID do processamento de transações podem ajudá-lo a conseguir isso.
3. Familiarize-se com o padrão MVC (se você ainda não estiver). Isso ajudará a melhorar seu design, mantendo uma separação de preocupações. Algumas estruturas populares, como Struts (Java) e MVC (.NET), são criadas em torno desse conceito.
4. Considere usar um plug-in como Java , Flash ou Silverlight para experiências de interface do usuário super-ricas. Para experiências semi-ricas, considere o uso de bibliotecas populares baseadas em java-script, como JQuery ou AJAX .

Boa programação!

Porque houve um tempo em que não havia milhões e milhões de páginas da web. Porque houve um tempo em que apenas universidades e instalações de pesquisa tinham algumas páginas. Houve um tempo em que não havia banda larga e o http foi comunicado com modems de 1200 baud colocados em cima dos telefones de mesa. Houve um tempo em que "aplicativos da web avançados" exigiam, na visão deles, uma quantidade ridícula de largura de banda. E lembre-se, o TCP / IP foi criado porque a Internet inicial não era muito confiável.

O HTTP 1.0 existia no início dos anos 90. Pense em como era a Internet da época e por que eles a projetaram da maneira que fizeram.

Tudo meio que evoluiu. A Internet existia antes dos navegadores e da Web. Era um pote borbulhante de ftp, telnet, gopher, ping, dedo e alguns outros pedaços. O primeiro navegador da web, Mosaic (acho que foi há muito tempo, 1991, acho que estava na faculdade) agia como uma espécie de confusão entre o ftp e o visualizador de documentos. A mágica aconteceu porque você poderia ter links no documento que aumentariam o tamanho de um novo documento.

Toda a interatividade que evoluímos ao longo dos próximos 20 anos. Também não foi uma evolução feliz. Tivemos as guerras entre navegadores, o IE e a Netscape disputaram o controle de padrões (um pouco de simplificação;)), e vários outros terceiros começaram a introduzir plug-ins para permitir conteúdo rico. Java seria a bala mágica e, claro, o Flash. Alguém se lembra dos plug-ins VRML que prometiam mundos 3D e entregavam exatamente meia dúzia de modelos 3D de modelos Star Wars?

Fiquei um pouco empolgado no final, mas você entendeu a ideia :)

Os principais motivos têm a ver com uma combinação do que a acedemia acreditava ser o objetivo do HTTP e por razões de escalabilidade. O HTML foi originalmente projetado para compartilhar informações ou teses através dos limites acadêmicos. Era um texto puramente estilizado. Não foi até o primeiro navegador permitir que você exibisse fotos que as pessoas começaram a pensar além desse modelo.

As considerações a seguir solidificaram a decisão apátrida:

• A interação típica seria um download rápido e uma leitura. Durante o atraso até a próxima solicitação, o soquete ficaria ocioso.
• Soquetes consomem preciosos recursos do sistema. Se não precisássemos manter uma conversa como você faria com o SMTP, você pode fazer muito para que uma máquina lide com milhares de clientes.
• Eles já aprenderam lições preciosas ao gerenciar contas de shell remotas, NFS, SMTP e outros protocolos de conexão com estado.

À medida que as páginas da Web se tornaram mais complexas e incluíam muitos gráficos e folhas de estilo, o HTTP foi corrigido com o sinalizador "keep-alive". Isso manteria o soquete ativo e permitiria ao cliente solicitar vários recursos com a mesma conversa.

Considerando o modelo de uso atual da Internet, a decisão original ainda é válida. Às vezes, pode ser inconveniente, mas várias interações pequenas e quantizadas com um servidor são dimensionadas melhor do que soquetes ociosos.

Se você quer dizer navegadores bidirecionais.

Razões de segurança.

Por exemplo SPAM !.

Levando a comunicação bidirecional na Web para o próximo nível

Caso contrário, a Internet executa TCP / IP (dois protocolos) e UDP.

O Protocolo de Controle de Transmissão(TCP) é um dos principais protocolos do Internet Protocol Suite. O TCP é um dos dois componentes originais do conjunto, complementando o IP (Internet Protocol) e, portanto, o conjunto inteiro é geralmente chamado de TCP / IP. O TCP fornece o serviço de troca de dados diretamente entre dois hosts na mesma rede, enquanto o IP lida com o endereçamento e o roteamento de mensagens em uma ou mais redes. Em particular, o TCP fornece entrega confiável e ordenada de um fluxo de bytes de um programa em um computador para outro programa em outro computador. TCP é o protocolo em que os principais aplicativos da Internet se baseiam, aplicativos como a World Wide Web, email e transferência de arquivos. Outras aplicações, que não requerem serviço confiável de fluxo de dados,

O Protocolo da Internet(IP) é o principal protocolo de comunicação usado para retransmitir datagramas (pacotes) através de uma internetwork usando o Internet Protocol Suite. Responsável pelo roteamento de pacotes através dos limites da rede, é o principal protocolo que estabelece a Internet. O IP é o protocolo principal na Camada da Internet do Internet Protocol Suite e tem a tarefa de fornecer datagramas do host de origem para o host de destino apenas com base em seus endereços. Para esse propósito, o IP define métodos e estruturas de endereçamento para encapsulamento de datagramas. Historicamente, IP era o serviço de datagrama sem conexão no Programa de Controle de Transmissão original, introduzido por Vint Cerf e Bob Kahn em 1974, o outro sendo o TCP (Transmission Control Protocol) orientado a conexão. O Internet Protocol Suite é, portanto, frequentemente chamado de TCP / IP.

Em um aplicativo de desktop, presume-se que o usuário esteja executando algumas séries de tarefas, com início e fim definidos. Em um aplicativo como esse, faz algum sentido (na verdade, não muito) que os usuários efetuem login em qualquer servidor que forneça seus dados e permaneçam conectados até que terminem.

As interações na Web (normalmente) não seguem o mesmo modelo. Em um site de comércio eletrônico, por exemplo, um usuário pode chegar a uma descrição do produto como resultado de uma pesquisa no Google e sair imediatamente dessa página para ver a oferta de outro site do mesmo produto. Ou então, ele pode iniciar o processo de pagamento e depois decidir que o produto é muito caro e abandoná-lo na metade. A idéia básica de "hipertexto" implica a capacidade e a expectativa de saltar de um local para outro.

Conexões permanentes consomem recursos. Talvez apenas um soquete de rede, talvez um pool de consultas de banco de dados analisadas; tudo depende da aplicação. Dado um usuário que pode desaparecer a qualquer momento, não faz muito sentido manter esses recursos comprometidos.

Na prática, não há necessidade real de o usuário ter uma conexão permanente. O aplicativo da web mantém conexões com quaisquer recursos (por exemplo, banco de dados) necessários e os compartilha entre todas as solicitações do usuário. A estrutura do aplicativo da web fornece sessões, que são locais com tempo limitado para armazenar dados por usuário para diferentes solicitações. A única coisa que você não pode fazer (facilmente) é ter transações controladas por clientes de longa execução, mas isso é uma má ideia, mesmo em um aplicativo que mantém conexões.

A Internet não é necessariamente sem estado - na verdade, quando você olha para o Java EE - eles têm EJBs com estado e EJBs sem estado.

A principal razão pela qual os desenvolvedores recomendam o uso de uma arquitetura sem estado é por causa da escalabilidade. Imagine tentar manter o estado de todos os seus usuários depois de adicionar e remover servidores para dar suporte ao seu tráfego.

Realmente não é difícil desenvolver uma arquitetura sem estado. O ponto principal é manter o mínimo de estado possível (geralmente um ID de usuário - de preferência em um cookie) e alterar o banco de dados conforme necessário.

Eu acho que começou assim e continuou sendo assim. Agora que há tanta infraestrutura construída em torno dele, é impossível alterá-la.

Talvez tenha começado sem estado porque as conexões eram menos confiáveis ​​no início e também a largura de banda era menor. Se você não tiver muitas conexões ativas, poderá lidar com mais tráfego com mais facilidade.

Por favor, edite ou deixe um comentário, se você tiver melhores informações, ou melhor ainda, poste sua própria resposta!

Isso porque os servidores fornecem um serviço (está no nome). Você faz uma solicitação e recebe respostas - isso é tudo.

No que diz respeito a fazer uma transição para o desenvolvimento da Web, acredito que o ASP.NET Web Forms fará isso de uma maneira que seja mais compreensível para você - mas é apenas porque oculta o que realmente está acontecendo sob as camadas de abstração.

Muito pode ser entendido analisando o nome do HTTP (HyperText Transfer Protocol). Ele nunca foi projetado para ser um rico protocolo de interface do usuário. A idéia original era compartilhar documentos com links entre eles. Peço um documento, você responde com uma cópia desse documento.

Originalmente, o HTTP tinha apenas um verbo GET. Nesse sentido, ele foi projetado para conteúdo estático. Por que você precisa indicar quando tudo o que você está fazendo é solicitar um documento que alguém está compartilhando? E é por isso que o HTTP é sem estado ... por causa de suas origens.