Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios orientados a objetos e TDD exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em projetar programas para Web e com dados armazenados em banco de dados, bem como em aplicar conceitos mais avançados de Java. O objetivo deste curso é enriquecer sua experiência com conceitos avançados de Java, programação de aplicações Web e acesso a banco de dados no contexto de modelagem ágil. Os conceitos apresentados neste curso no contexto da programação Java incluem o seguinte: APIs fundamentais do Java: tipos genéricos, reflexão e anotações; expressões lambda do Java 8; aplicação Web com Java: Java Servlets, páginas JSP, padrão MVC e teste de aplicação Web com Selenium; e acesso a banco de dados em Java: JDBC, desenvolvimento de aplicação empresarial e testes com DBUnit. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar de modo ágil uma versão inicial da aplicação Web em associação com o componente de gamificação constantes do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Fundamentos de Aplicações Web
Loading...
Del curso dictado por Instituto Tecnológico de Aeronáutica
Desenvolvimento Ágil com Java Avançado
167 calificaciones
De la lección
Semana 1
Olá, bem-vindo ao Curso 3 – Desenvolvimento Ágil com Java Avançado. Neste módulo você será introduzido ao maravilhoso mundo das aplicações Web com Java, criando páginas dinâmicas com servlets e conduzindo testes de aplicações Web por meio da ferramenta Selenium. Você será exposto também aos tipos genéricos do Java, entendendo os conceitos subjacentes e fazendo uso deles para prover tanto segurança de tipo em tempo de compilação, quanto para reduzir código redundante em exemplo prático.
Conoce a los instructores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
