Entendendo a internet sem estados [fechada]


Estou mudando de desenvolvedor de área de trabalho para desenvolvedor da Web e estou tendo problemas para entender por que o HTTP é sem estado. Quais são as razões para isso? Quais são algumas maneiras pelas quais um desenvolvedor de área de trabalho como eu pode fazer a transição para um ambiente de desenvolvimento sem estado?

por P.Brian.Mackey 18.01.2011 / 16:16

12 respostas


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

Como expliquei REST para minha esposa

Wife: Who is Roy Fielding?

Ryan: Some guy. He's smart.

Wife: Oh? What did he do?

Ryan: He helped write the first web servers and then did a ton of research explaining why the web works the way it does. His name is on the specification for the protocol that is used to get pages from servers to your browser.

Wife: How does it work?

Ryan: The web?

Wife: Yeah.

Ryan: Hmm. Well, it's all pretty amazing really. And the funny thing is that it's all very undervalued. The protocol I was talking about, HTTP, it's capable of all sorts of neat stuff that people ignore for some reason.

Wife: You mean http like the beginning of what I type into the browser?

Ryan: Yeah. That first part tells the browser what protocol to use. That stuff you type in there is one of the most important breakthroughs in the history of computing.

Wife: Why?

Ryan: Because it is capable of describing the location of something anywhere in the world from anywhere in the world. It's the foundation of the web. You can think of it like GPS coordinates for knowledge and information.

Wife: For web pages?

Ryan: For anything really. That guy, Roy Fielding, he talks a lot about what those things point to in that research I was talking about. The web is built on an architectural style called REST. REST provides a definition of a resource, which is what those things point to.

Wife: A web page is a resource?

Ryan: Kind of. A web page is a representation of a resource. Resources are just concepts. URLs--those things that you type into the browser...

Wife: I know what a URL is..

Ryan: Oh, right. Those tell the browser that there's a concept somewhere. A browser can then go ask for a specific representation of the concept. Specifically, the browser asks for the web page representation of the concept.

Wife: What other kinds of representations are there?

Ryan: Actually, representations is one of these things that doesn't get used a lot. In most cases, a resource has only a single representation. But we're hoping that representations will be used more in the future because there's a bunch of new formats popping up all over the place.

Wife: Like what?

Ryan: Hmm. Well, there's this concept that people are calling Web Services. It means a lot of different things to a lot of different people but the basic concept is that machines could use the web just like people do.

Wife: Is this another robot thing?

Ryan: No, not really. I don't mean that machines will be sitting down at the desk and browsing the web. But computers can use those same protocols to send messages back and forth to each other. We've been doing that for a long time but none of the techniques we use today work well when you need to be able to talk to all of the machines in the entire world.

Wife: Why not?

Ryan: Because they weren't designed to be used like that. When Fielding and his buddies started building the web, being able to talk to any machine anywhere in the world was a primary concern. Most of the techniques we use at work to get computers to talk to each other didn't have those requirements. You just needed to talk to a small group of machines.

Wife: And now you need to talk to all the machines?

Ryan: Yes - and more. We need to be able to talk to all machines about all the stuff that's on all the other machines. So we need some way of having one machine tell another machine about a resource that might be on yet another machine.

Wife: What?

Ryan: Let's say you're talking to your sister and she wants to borrow the sweeper or something. But you don't have it - your Mom has it. So you tell your sister to get it from your Mom instead. This happens all the time in real life and it happens all the time when machines start talking too.

Wife: So how do the machines tell each other where things are?

Ryan: The URL, of course. If everything that machines need to talk about has a corresponding URL, you've created the machine equivalent of a noun. That you and I and the rest of the world have agreed on talking about nouns in a certain way is pretty important, eh?

Wife: Yeah.

Ryan: Machines don't have a universal noun - that's why they suck. Every programming language, database, or other kind of system has a different way of talking about nouns. That's why the URL is so important. It let's all of these systems tell each other about each other's nouns.

Wife: But when I'm looking at a web page, I don't think of it like that.

Ryan: Nobody does. Except Fielding and handful of other people. That's why machines still suck.

Wife: What about verbs and pronouns and adjectives?

Ryan: Funny you asked because that's another big aspect of REST. Well, verbs are anyway.

Wife: I was just joking.

Ryan: It was a funny joke but it's actually not a joke at all. Verbs are important. There's a powerful concept in programming and CS theory called polymorphism. That's a geeky way of saying that different nouns can have the same verb applied to them.

Wife: I don't get it.

Ryan: Well.. Look at the coffee table. What are the nouns? Cup, tray, newspaper, remote. Now, what are some things you can do to all of these things?

Wife: I don't get it...

Ryan: You can get them, right? You can pick them up. You can knock them over. You can burn them. You can apply those same exact verbs to any of the objects sitting there.

Wife: Okay... so?

Ryan: Well, that's important. What if instead of me being able to say to you, "get the cup," and "get the newspaper," and "get the remote"; what if instead we needed to come up with different verbs for each of the nouns? I couldn't use the word "get" universally, but instead had to think up a new word for each verb/noun combination.

Wife: Wow! That's weird.

Ryan: Yes, it is. Our brains are somehow smart enough to know that the same verbs can be applied to many different nouns. Some verbs are more specific than others and apply only to a small set of nouns. For instance, I can't drive a cup and I can't drink a car. But some verbs are almost universal like GET, PUT, and DELETE.

Wife: You can't DELETE a cup.

Ryan: Well, okay, but you can throw it away. That was another joke, right?

Wife: Yeah.

Ryan: So anyway, HTTP--this protocol Fielding and his friends created--is all about applying verbs to nouns. For instance, when you go to a web page, the browser does an HTTP GET on the URL you type in and back comes a web page.

Web pages usually have images, right? Those are separate resources. The web page just specifies the URLs to the images and the browser goes and does more HTTP GETs on them until all the resources are obtained and the web page is displayed. But the important thing here is that very different kinds of nouns can be treated the same. Whether the noun is an image, text, video, an mp3, a slideshow, whatever. I can GET all of those things the same way given a URL.

Wife: Sounds like GET is a pretty important verb.

Ryan: It is. Especially when you're using a web browser because browsers pretty much justGET stuff. They don't do a lot of other types of interaction with resources. This is a problem because it has led many people to assume that HTTP is just for GETing. But HTTP is actually ageneral purpose protocol for applying verbs to nouns.

Wife: Cool. But I still don't see how this changes anything. What kinds of nouns and verbs do you want?

Ryan: Well the nouns are there but not in the right format.

Think about when you're browsing around amazon.com looking for things to buy me for Christmas. Imagine each of the products as being nouns. Now, if they were available in a representation that a machine could understand, you could do a lot of neat things.

Wife: Why can't a machine understand a normal web page?

Ryan: Because web pages are designed to be understood by people. A machine doesn't care about layout and styling. Machines basically just need the data. Ideally, every URL would have a human readable and a machine readable representation. When a machine GETs the resource, it will ask for the machine readable one. When a browser GETs a resource for a human, it will ask for the human readable one.

Wife: So people would have to make machine formats for all their pages?

Ryan: If it were valuable.

Look, we've been talking about this with a lot of abstraction. How about we take a real example. You're a teacher - at school I bet you have a big computer system, or three or four computer systems more likely, that let you manage students: what classes they're in, what grades they're getting, emergency contacts, information about the books you teach out of, etc. If the systems are web-based, then there's probably a URL for each of the nouns involved here: student, teacher, class, book, room, etc. Right now, getting the URL through the browser gives you a web page. If there were a machine readable representation for each URL, then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way. It would also make it quite a bit easier for each of the systems to talk to each other. Or, you could build a state or country-wide system that was able to talk to each of the individual school systems to collect testing scores. The possibilities are endless.

Each of the systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT. The only thing left to figure out is what the data should look like.

Wife: So this is what you and all the computer people are working on now? Deciding what the data should look like?

Ryan: Sadly, no. Instead, the large majority are busy writing layers of complex specifications for doing this stuff in a different way that isn't nearly as useful or eloquent. Nouns aren't universal and verbs aren't polymorphic. We're throwing out decades of real field usage and proven technique and starting over with something that looks a lot like other systems that have failed in the past. We're using HTTP but only because it helps us talk to our network and security people less. We're trading simplicity for flashy tools and wizards.

Wife: Why?

Ryan: I have no idea.

Wife: Why don't you say something?

Ryan: Maybe I will.

por 18.01.2011 / 16:29

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? :) Então você só armazena o estado onde for necessário, em sessões.

BTW: o HTTP não é sem conexão.

por 18.01.2011 / 16:20

Como desenvolvedor de área de trabalho, talvez você se sinta mais à vontade com experiências ricas de interface do usuário. Mover-se 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 isso te derrubar! Existem várias coisas que podem ajudá-lo a fazer a transição e aqui está uma pequena lista delas:

  1. O estado pode ser compartilhado, mas é frequentemente mantido no servidor e referenciado usando tokens, como id da sessão, parâmetros de URL, campos ocultos ou valores de cookies.
  2. Os modelos sem estado são adequados para o processamento de transações. Tente construir seu modelo de tal forma que possa reduzir a quantidade de estado necessária. Os princípios de processamento de transação do ACID podem ajudá-lo a conseguir isso.
  3. Familiarize-se com o padrão MVC (se você não for já). Isso ajudará a melhorar seu design, mantendo uma separação de interesses. Alguns frameworks populares como Struts (Java) e MVC (.NET) são construídos em torno deste conceito.
  4. Considere usar um plug-in como Java , Flash ou Silverlight para obter experiências de UI super-ricas. Para experiências semi-ricas, considere o uso de bibliotecas populares baseadas em scripts Java, como JQuery ou AJAX .

Feliz programação!

por 18.01.2011 / 17:28

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 centros 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 "rich web apps" teriam requerido, em sua opinião, uma quantidade ridícula de largura de banda. E lembre-se, o TCP / IP foi criado porque a internet antiga não era muito confiável.

O HTTP 1.0 existia no início dos anos 90. Pense em como a internet de então foi e por que eles projetaram da maneira que fizeram.

por 18.01.2011 / 16:24

Tudo evoluiu. A Internet existia antes dos navegadores da Web e da Web. Era um pote borbulhante de ftp, telnet, gopher, ping, finger e alguns outros bits e bobs. O primeiro navegador da web, o Mosaic (acho que foi há muito tempo, acho que eu estava na faculdade em 1991) agia como uma espécie de mistura entre ftp e um visualizador de documentos. A mágica aconteceu em que você poderia ter links no documento que colocariam um novo documento.

Toda a interatividade que temos agora evoluiu ao longo dos 20 anos seguintes. Não foi uma evolução feliz também. Tivemos as guerras dos navegadores, o IE e o Netscape disputaram o controle de padrões (um tanto simplificado;)), 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 do plug-in VRML que prometia mundos 3D e entregou exatamente meia dúzia de modelos 3D de modelos de Guerra nas Estrelas?

Eu me empolguei um pouco no final, mas você entendeu:

por 18.01.2011 / 16:30

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

As seguintes considerações solidificaram a decisão apatridida:

  • A interação típica seria um download rápido e a leitura. Durante o atraso até o próximo pedido, a tomada ficaria inativa.
  • Os soquetes usam recursos preciosos do sistema. Se não tivéssemos que manter uma conversa como você faria com o SMTP, você pode fazer muito para que uma máquina manipule milhares de clientes.
  • Eles já aprenderam preciosas lições com o gerenciamento de contas de shell remotas, NFS, SMTP e outros protocolos de conexão com informações de 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 alterado com o sinalizador "keep-alive". Isso manteria o socket ativo e permitiria que o cliente solicitasse vários recursos com a mesma conversa.

Considerando o atual modelo de uso da internet, a decisão original ainda é válida. Pode ser inconveniente às vezes, mas várias interações pequenas e quantizadas com um servidor são melhores do que as tomadas ociosas.

por 18.01.2011 / 16:33

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.

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides the service of exchanging data directly between two hosts on the same network, whereas IP handles addressing and routing message across one or more networks. In particular, TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications rely on, applications such as the World Wide Web, e-mail, and file transfer. Other applications, which do not require reliable data stream service, may use the User Datagram Protocol (UDP) which provides a datagram service that emphasizes reduced latency over reliability.

The Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (packets) across an internetwork using the Internet Protocol Suite. Responsible for routing packets across network boundaries, it is the primary protocol that establishes the Internet. IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation. Historically, IP was the connectionless datagram service in the original Transmission Control Program introduced by Vint Cerf and Bob Kahn in 1974, the other being the connection-oriented Transmission Control Protocol (TCP). The Internet Protocol Suite is therefore often referred to as TCP/IP.

por 18.01.2011 / 16:19

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 tal aplicativo, faz algum sentido (não muito, na verdade) que os usuários se conectem a qualquer servidor que forneça seus dados e permaneçam conectados até que estejam prontos.

As interações da Web não seguem (tipicamente) 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 imediatamente deixar essa página para ver a oferta de outro site do mesmo produto. Ou ele pode começar o processo de checkout, então decidir que o produto é muito caro e abandoná-lo no meio do processo. A idéia básica de "hipertexto" implica a habilidade e a expectativa de pular de um local para outro.

Conexões permanentes consomem recursos. Talvez apenas um soquete de rede, talvez um conjunto 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) de que precisa e os compartilha entre todas as solicitações do usuário. A estrutura de 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 pelo cliente de longa duração, mas isso é uma má ideia, mesmo em um aplicativo que mantém conexões.

por 18.01.2011 / 17:01

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.

O principal motivo pelo qual os desenvolvedores recomendam o uso de uma arquitetura sem estado é devido à escalabilidade. Imagine tentar manter o estado de todos os seus usuários quando você estiver adicionando e descartando servidores para suportar seu tráfego.

Não é realmente difícil desenvolver uma arquitetura sem estado. O ponto principal é manter o menor estado possível (geralmente um ID de usuário - preferencialmente em um cookie) e alterar o banco de dados conforme necessário.

por 18.01.2011 / 16:54

Acho que começou assim e continuou sendo assim. Agora que há muita infraestrutura construída em torno dela, é impossível alterá-la.

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

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

por 18.01.2011 / 16:23

É porque os servidores fornecem um serviço (está no nome). Você faz um pedido e recebe respostas - isso é tudo que existe.

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

por 18.01.2011 / 16:27

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

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

por 18.01.2011 / 18:20