[MÚSICA] Olá você! Estamos aqui agora com curso de Desenvolvimento Ágil com Java Avançado e, nesse módulo, vamos estar falando sobre aplicações Web. Hoje, na aula vamos falar sobre os fundamentos das aplicações Web. Eu vejo que tem muita gente que às vezes começa, pega, já aprende a pegar e fazer, a colocar sem entender direito como é que as aplicações Web funcionam e às vezes quando aparecem alguns conceitos nem sabe que é que aquilo ali quer dizer. Então, hoje nessa aula vamos estar falando aí sobre esses fundamentos, como é que funciona uma aplicação Web. A primeira coisa que a gente tem que saber as páginas Web, elas não foram feitas para ter conteúdo dinâmico. A princípio elas foram feitas para você conseguir navegar documentos de hipertexto. O que é que é o hipertexto? É documento que você vai lendo e aí, por exemplo, você pode ter links onde você clica e vai navegando não é? O hipertexto é essa ideia do navegar ou surfar na Internet, que você vai lendo, aí acha uma coisa de interesse, aí você clica e vai para uma outra página e, a princípio eram apenas páginas estáticas. O protocolo que se utilizava para fazer essa navegação é protocolo chamado HTTP. O HTTP é Hypertext Transfer Protocol e seria protocolo de transferência de hipertexto. Hoje dia a gente utiliza o HTTP para transferir vários outros tipos de documento, não só hipertexto, que no caso seria o HTML, mas a gente usa para transferir figuras, muitas vezes até para fazer requisições de chamadas remotas de sistema com webservers. Então hoje o HTTP é protocolo muito mais amplo, que tem uma gama aí de utilização muito maior do que apenas para hipertexto. E, uma característica importante desse protocolo HTTP, é que ele é protocolo de pergunta e resposta. Então, a gente tem ali o request, que é, quando a gente faz uma requisição de uma página a gente envia request e aí o servidor Web, o que está hospedando ali as páginas, ele vai responder com response. Então, assim, é isto, o protocolo HTTP é isto. Uma questão importante que a gente tem que entender do protocolo HTTP é que ele não mantém uma conexão ativa, ele é simplesmente uma pergunta e uma resposta. Então, por exemplo, se você está num site você loga, você faz outras coisas, você não está mantendo uma conexão ativa com aquele site. Pede uma página ou uma informação, é uma conexão que ele faz, ele te retorna e ali aquela conexão encerra. Então, por causa disso até, a gente vai ver nas aulas mais para a frente, como que isso gerou algum problemas que precisaram ser tratados aí de uma outra forma. Vamos ver pouquinho mais do protocolo HTTP. O request, ele tem aí essa cara, esse formato. A primeira informaçãozinha que a gente tem ali cima é o método que no caso ali seria get, a gente tem o get e o post, nessa aula mesmo a gente fala mais pouquinho mais sobre isso, depois a gente tem o recurso que está sendo, que no caso ali é a página htm, e aí a gente tem o que a gente chama de headers que são informações que a gente pode ter, como por exemplo, os tipos que ele aceita, qual que é o browser que a gente está utilizando, qual que é a língua. Muitas vezes a gente acessa site de lugar sendo que o nosso sistema operacional está português, a página já vem português, ou já vem inglês dependendo do sistema operacional. Como que a página faz isso? Pegando a língua do sistema a partir do header. Então, a partir desse request a gente também pode passar parâmetros, a gente vai ver também, nessa aula ainda, como que a gente pode fazer isso e como que isso funciona diferente para os diferentes métodos HTTP. Bom, vamos ver pouquinho agora do response que seria a resposta. Então, a primeira coisa que a gente tem é o código de status, então a gente tem ali por exemplo 200, que seria que está tudo OK, mas tenho certeza que vocês já viram aí o código 404, que é quando alguma coisa não é encontrada, ou o código 500, que é o internal server error, então eu desafio vocês aí a dar uma procurada na Internet dos códigos de resposta HTTP para você dar uma olhada como que eles funcionam. E, além desse código a gente também tem esses headers, importante é o content type que diz o tipo de conteúdo que está ali, então, se no caso ali text HTML o navegador vai interpretar como HTML, mas se fosse uma figura, ou PDF, o browser trataria isso de uma forma diferente. E aí, por fim, a última partezinha aqui é o conteúdo si, que vai ter ali o HTML, a imagem, o conteúdo si da requisição que está sendo solicitada. Bom, eu queria falar pouquinho agora sobre URL. Eu vou até sair pouco aqui de cena para vocês poderem ver de uma forma mais completa o slide. A primeira coisa que a gente tem no URL é o protocolo, então a gente tem ali o http://. Tenho certeza que vocês já viram outros protocolos, hoje dia por exemplo o HTTPS é muito utilizado, antigamente tinha outros como o GOPHER, o próprio SMTP para e-mails, então, a primeira coisa que vem ali na URL é o protocolo. Depois, vem o servidor, normalmente o nome do site, ele pode ser trocado ali por exemplo por IP, na verdade aquilo ali é o nome do site mas poderia ser o IP. Depois, a gente tem dois pontos e a porta, a porta normal de uma página do protocolo HTTP é a porta 80, justamente por isso a gente vai ver que quando a gente fizer o deploy, a gente estiver testando uma aplicação Web, normalmente ele vai usar uma porta diferente como a porta 8080, 8081, são portas comuns que os webservers costumam utilizar, principalmente para teste, para você rodar na sua máquina a página e ver se está tudo funcionando. O caminho que, por exemplo, seriam diretórios, eles podem ser reais ou virtuais, você pode mapear as coisas. Depois, recurso que vai ser uma página ou uma figura, alguma coisa que você está querendo acessar e aí, por fim, os parâmetros que depois do recurso a gente tem uma interrogação, esses parâmetros, essa forma de passar parâmetros a gente chama de query string. E aí a gente tem por exemplo interrogação, aí a gente tem o nome do parâmetro igual a 1 ou igual ao valor e aí a gente separa por aquele e comercial, ou como eu gosto de chamar o e de dupla sertaneja, e bota ali vai seguindo com as variáveis. Então, no caso ali eu tenho parâmetro v1 igual a e parâmetro v2 igual a OK. Deixa eu voltar. Uma coisa importante é que a gente não pode encarar essas coisas como: " se eu tenho diretório então, ele com certeza lá no servidor tem esse diretório". Tudo isso a gente pode mapear para recursos. Tem aplicações que inclusive utilizam o próprio endereço como se fosse uma estrutura de diretórios para passar parâmetros. Tudo isso é acessível dentro da sua aplicação e aí você pode pegar essa URL e interpretar ela e fazer o que você quiser com o formato dela. Esse é o formato básico mas a gente tem uma certa flexibilidade relação a isto. Outra coisa importante de a gente entender são os métodos HTTP. A gente tem vários, tem o delete, tem o post, tem outros aí que a gente pode estar utilizando, mas o dois principais são o get e o post e é importante neste momento a gente entender a diferença entre eles. Se a gente for falar de uma forma, assim o uso normal, o get é como se você acessasse link e o post é como se você estivesse submetendo formulário. Porque é que eu disse o uso normal? Porque, tanto você pode clicar num link e ter post, quanto você pode submeter formulário e ser get. Isso seria meio que o uso normal que a gente tem assim como principal uso daquele método. A principal diferença termos de, falando aí termos de protocolo, é justamente como que você passa os parâmetros. Então eu vou voltar pouquinho aqui os slides para a gente entender. Então, por exemplo, quando eu tenho método get eu vou aqui na minha requisição passar os parâmetros por query string como a gente viu ali na URL, com a interrogação e separando os parâmetros naquele e comercial. Ali, do lado ali, onde eu tenho página hmt, eu passaria os parâmetros. Quando eu passo os parâmetros por post, os parâmetros eles vão no corpo da requisição, ou seja, baixo de tudo aqui vão ir os parâmetros, então dá para a gente perceber só por isso que, se eu tenho parâmetros muito grandes, até mesmo porque a URL ela tem limite que eu tenho que obedecer, eu não posso passar parâmetro muito grande, por exemplo se eu tiver text array que eu tiver submetendo num formulário, isso daí já não é adequado de ser enviado por get. E aí assim, qual que é o real uso? Quando que eu vou fazer formulário ser submetido por get, quando que eu vou fazer link submeter as informações por post? A grande questão é que get ele não pode ter efeitos colaterais, teoricamente get é uma coisa que você pode repetir várias vezes dentro do sistema sem que aquilo mude, então normalmente quando a gente fala isso a gente está recuperando informações. Então, por exemplo, formulário que poderia ser submetido por get, por exemplo, formulário de busca, que por exemplo, vai te dar resultado, não tem problema, você pode fazer aquela busca várias e várias vezes que não vai gerar efeito colateral no sistema. Inclusive, uma coisa que eu gosto de usar como critério para saber se eu uso o get ou o post, eu sempre penso "O resultado disso daqui pode ser adicionado nos favoritos?". Então por exemplo, uma busca faz sentido, o cara fez a busca ali " eu quero fazer essa busca mais vezes e tal", e aí ele vai e adiciona aquilo nos favoritos. O post, ele já representa requisições que têm efeito colateral no servidor, então, que não faz muito sentido você estar indo lá e repetindo aquela requisição muitas vezes. Então, por exemplo, se você está fazendo o cadastro de usuário não faz sentido você ir lá e cadastrar ele várias vezes, submeter aquilo ali várias vezes. Porquê? Porque aquilo ali vai cadastrar vários usuários e não é isso que você quer. Então, por esse motivo mesmo, às vezes até quando a gente tenta voltar, que a gente fez post, o próprio navegador pergunta: " você tem certeza que você vai fazer isso daí? Você quer ressubmeter esse formulário?". E por isso mesmo você não consegue uma submissão de formulário adicionar aquele resultado ali no seu favorito, porque não faz sentido. " eu fiz cadastro, eu quero adicionar no meu favorito e submeter esse cadastro", não faz sentido. Então, o principal critério que eu utilizo, entre utilizar o get e o post é eu vou utilizar get quando for uma requisição que não tiver efeito colateral e eu vou utilizar o post quando for uma requisição que se eu submeter ela repetidas vezes eu vou gerar efeito colateral. Uma outra questão que eu escuto bastante e, por mais que não esteja aqui no escopo do nosso curso, dar curso sobre de aplicações, tem algumas coisas que eu acho importante falar. Qual dos dois métodos, o get ou o post, você acha mais seguro? Responda aí. Na verdade, nenhum dos dois é seguro. Muita gente diz que o fato de você não passar as informações na URL isso daí deixa o post seguro. Lógico que se você esconder, o cara não vai poder guardar ali nos favoritos dele, sei lá uma senha, na própria URL. Mas por outro lado, hacker ou alguém com a miníma habilidade que conseguir capturar a sua requisição vai capturar ela sendo post ou get. Então, não conte com o fato: " não vou usar o post porque é mais seguro". Não, nenhum dos 2 na realidade é seguro e, a gente tem que utilizar outras formas, como protocolo HTTPS e outras alternativas, outros mecanismos aí de segurança, para deixar essa requisição segura. O simples fato, eu não gosto que digam que o post é mais seguro porque parece que: " não, vou fazer o post está tudo certo". Não, não está tudo certo, nenhum dos dois é seguro e a gente tem que tomar cuidado com isso. Só queria deixar isso claro já que estamos falando aqui sobre os métodos HTTP. Então, com isso nessa aula eu espero que a gente tenha conseguido cobrir aí os básicos de uma aplicação Web, entender como funciona o protocolo HTTP, como a URL, os principais métodos, o get e o post para que a gente possa nas próximas aulas estar entrando aí nas aplicações Web e você entendendo que é que são aquelas coisas que a gente está recuperando que a gente está setando ali na hora de processar uma requisição. Muito obrigado, até à próxima aula. [MÚSICA] [MÚSICA]
