CURSO HTTP

Prévia do material em texto

CURSO HTTP: ENTENDENDO A WEB POR BAIXO DOS PANOS
MÓDULO 01 O QUE É HTTP? (Hypertext Transfer Protocol)
Nesse treinamento focaremos nos fundamentos da web. Isto é importante pois a grande maioria das aplicações hoje em dia a utilizam de alguma forma ou funcionam dentro dela. Não focaremos em nenhuma plataforma específica de desenvolvimento como Java ou PHP. Focaremos nas regras de comunicação da web.
Quando se fala em HTTP, o primeiro pensamento que vem a nossa mente é sobre a utilização da internet, é o cenário onde vemos realmente na prática a utilização do HTTP. Nós acessamos sites em que seus endereços iniciam com http:// e por isso precisamos conhecer o que realmente está acontecendo ao fazer isso.
No momento em que acessou este curso, esta aula, entre o navegador e a Alura aconteceu uma comunicação, e esta comunicação tem duas partes bem conhecidas que chamamos de Client-Server ou em português Cliente-Servidor. Este é um modelo arquitetural, ou seja, a internet inteira é baseada nesta arquitetura onde há um cliente que solicita e um servidor que responde.
Em qualquer comunicação é preciso existir algumas regras para que as duas partes consigam se entender com sucesso. Pensando na comunicação do seu navegador entre a Alura ou algum outro site esse conjunto de regras é basicamente um protocolo, onde neste cenário é o HTTP.
Os protocolos são definidos, especificados e disponibilizados para implementação em ambas as partes, para consultar a especificação do HTTP, você pode utilizar o seguinte endereço: https://tools.ietf.org/html/rfc2616
Resumindo: O HTTP é um protocolo que define as regras de comunicação entre cliente e servidor na internet. Vamos focar nos próximos vídeos e entender melhor esse protocolo tão importante. mãos a obra!
O que aprendemos neste capítulo?
· Na internet sempre tem um cliente e um servidor
· Entre o cliente e o servidor precisam haver regras de comunicação
· As regras são definidas dentro de um protocolo
· HTTP é o protocolo mais importante na internet
Qual é o papel do HTTP entre o cliente e o servidor? O HTTP foi feito para estabelecer regras de comunicação entre o modelo Cliente-Servidor que funciona na Web.
Para saber mais: Peer-To-Peer
Você já usou torrent para baixar algum arquivo na internet? Caso sim, aproveitou um outro modelo de comunicação, o P2P ou Peer-To-Peer!
O modelo Cliente-Servidor não é o único modelo de comunicação na rede, nem sempre o mais adequado. Por exemplo, imagine que precisemos contar as letras de 20 palavras. No caso do modelo Cliente-Servidor, quem fará esse trabalho é o servidor, certo? E se precisar contar as letras de 1 milhão de palavras? Muito trabalhoso para o servidor, não?
O modelo Cliente-Servidor tenta centralizar o trabalho no servidor, mas isso também pode gerar gargalos. Se cada Cliente pudesse ajudar no trabalho, ou seja, assumir um pouco da responsabilidade do servidor, seria muito mais rápido. Essa é a ideia do P2P! Não há mais uma clara divisão entre Cliente-Servidor, cada cliente também é servidor e vice-versa!
Isto é útil quando você precisa distribuir um trabalho ou necessita baixar algo de vários lugares diferentes. Faz sentido?
Usando algum aplicativo de Torrent, o protocolo utilizado não é o HTTP, e sim o protocolo P2P, como BitTorrent ou Gnutella.
O HTTP não é o único protocolo de comunicação que existe. Aliás, existem milhares de protocolos no mundo de TI, no entanto o HTTP é de longe o mais popular.
- SMTP: Simple Mail Transfer Protocol, protocolo para enviar e-mails
- BitTorrent: Além de ser um protocolo, também é um aplicativo para troca de arquivos na internet
- FTP: File Transport Protocol, protocolo para transferir arquivos
Para saber mais: Arquitetura da Alura
Agora já sabemos que existe um cliente, o navegador, como Chrome e Firefox, e um servidor, a Alura. Para definir as regras de comunicação entre cliente e servidor, existe o protocolo HTTP.
Também já sabemos que o servidor usa alguma plataforma, como PHP, Java, .Net ou outros. Qual plataforma realmente é utilizada? Não é tão fácil de descobrir, pois o HTTP, de propósito, não está focado em alguma plataforma específica e esconde isso de nós. Bom, eu não vou esconder nada e vou contar para vocês que a Alura usa a plataforma Java e o servidor concreto se chama Tomcat.
Também já falamos que o SQL é uma linguagem para consultar o banco de dados. Alura usa SQL para acessar o banco de dados MySQL.
Com essas informações já temos uma breve ideia da arquitetura da Alura!
Cliente <--- HTTP ---> Servidor Java <--- SQL ---> Banco de dados
Visualizando:
Há arquiteturas muito mais complexas, mas a grande maioria usa o protocolo HTTP no topo. O protocolo HTTP garante a conectividade. Isso quer dizer que o protocolo HTTP funciona em todos os lugares, sem ter problemas com firewalls e outras regras de segurança. Nós podemos nos conectar sem maiores problemas com qualquer servidor no mundo!
O que você aprendeu nesse capítulo?
· A arquitetura Cliente-Servidor
· Um protocolo é um conjunto de regras
· HTTP é um protocolo que define as regras de comunicação entre cliente e servidor na internet.
· HTTP é o protocolo mais importante da Internet
MÓDULO 02 - HTTPS: A WEB SEGURA
Sabendo que o HTTP é o protocolo que define as regras de comunicação na web, precisamos observar algumas coisas. Quando usamos o HTTP, todos os dados enviados entre cliente e servidor são transmitidos em texto puro, inclusive dados sensíveis, como login e senha!
Quando acessamos a Alura por exemplo, precisamos fornecer informações de autenticação, essas informações são nosso email e senha, que são enviadas e validadas pela plataforma para que assim consigamos assistir as aulas. Estas informações são enviadas em texto limpo e é possível visualizá-las pelas ferramentas do desenvolvedor do navegador. A aba network nos possibilita isso.
Mas por que é importante sabermos isso? Quando o navegador pede informações da Alura, nessa comunicação há vários intermediários. Por exemplo, usando uma conexão Wi-Fi, os dados do navegador passam primeiro para o roteador Wi-Fi, e do roteador passam para o modem do provedor, do modem para algum servidor do provedor de internet, como Oi ou NET.
É muito provável que existam outros servidores intermediários no provedor antes que os dados realmente cheguem no servidor da Alura. Com a resposta é a mesma coisa, ela volta passando por esses servidores no meio antes de chegar até nosso navegador. O problema é, quando usamos HTTP, qualquer servidor no meio pode espionar os dados enviados, algo totalmente inseguro! Imagine se essas informações fossem relativas a contas bancárias. Não seria nada seguro!
Para estes outros cenários, existe o HTTPS, que basicamente é o HTTP comum, porém com uma camada adicional de segurança/criptografia que antes era SSL, mas posteriormente passou a ser também TLS. É muito comum que estas duas siglas sejam encontradas juntas como SSL/TLS por se tratarem da mesma questão de segurança. Sendo assim, temos dois termos:
1. HTTP: HyperText Transfer Protocol
2. SSL/TLS: Secure Sockets Layer / Transport Layer Security
O que acontece com nossos dados quando usamos HTTP , ou seja sem a letra S ao final?
Os dados são transportados em texto puro para o servidor, visível para qualquer um. Exato, nossos dados são enviados em texto puro, ficando visível para qualquer um que consiga interceptar nossa conexão! Quando usamos HTTP, os dados são enviados em texto puro. O que pode ser perigoso, já que assim deixamos os dados abertos para intermediários.
Ao acessarmos o site da Alura pelo navegador podemos perceber que ele já usa o protocolo HTTPS:
Reparem que no navegador, ao lado do https, aparece um cadeado e que ao clicarmos no cadeado podemos ver mais informações sobre HTTPS. Uma dessas informações indica que a Alura tem uma identidade confirmada. O que isso quer dizer?
O HTTPS para garantir segurança usa criptografia baseada em chaves públicas e privadas e para gerar essas chaves públicas e privadas é preciso garantir a identidade de quem possui essas chavese isso é feito a partir de um certificado digital, ou seja, um certificado digital é utilizado para identificar determinada entidade e ainda é utilizada para geração das chaves de criptografia.
Apesar disso, ainda é necessário que uma autoridade certificadora, que nada mais é que um órgão ou entidade confiável, garanta não apenas a identidade do site mas também a validade do certificado. No caso da Alura a autoridade certificadora é a COMODO RSA Domain Validation, mas existem outras.
Dito isso, como tudo funciona? Os navegadores em posse da chave pública criptografam as informações e as enviam para o servidor que as descriptografa com a chave privada. É importante notar que apenas a chave privada descriptografa as informações criptografadas com a pública, e também que deve-se manter a chave privada segura.
O que aprendemos nesse capítulo?
· Só com HTTPS a web é segura.
· HTTPS significa usar um certificado digital no servidor.
· O certificado prova a identidade e tem validade
· O certificado possui uma chave publica.
· A chave é utilizada pelo navegador para criptografar os dados.
Certificado digital
Quando precisamos informar nossos dados a algum servidor, queremos ter certeza que este servidor realmente representa a entidade em questão. Queremos confiar em quem estamos fornecendo nossos dados!
Um certificado digital prova uma identidade para um site, onde temos informações sobre o seu domínio e a data de expiração desse certificado.
Além disso, o certificado ainda guarda a chave pública que é utilizada para criptografar (cifrar) os dados que são trafegados entre cliente e servidor.
Características do HTTPS
- A chave privada fica apenas no lado do servidor, é utilizada para descriptografar os dados que foram criptografados com a chave pública, por isso ela é importante e deve ficar apenas em posse do servidor. 
- O certificado prova a identidade e tem validade. Todo certificado tem uma data validade e serve para provar a identidade entre o cliente e o servidor. 
- O certificado guarda a chave pública. Nele encontramos a chave pública utilizada para criptografar os nossos dados.
Parte inferior do formulário
Lembrando o HTTP não utiliza criptografia nenhuma e é inseguro! Para deixar a web segura devemos usar o HTTPS sempre.
Qual é a finalidade das autoridades certificadoras? 
Garantir que podemos confiar naquele certificado (identidade), ou seja, que os certificados que estão sendo utilizados podem ser confiados. Essa garantia é feita através de uma assinatura digital. A autoridade certificadora (CA) assina digitalmente o certificado! Como na vida real, existem também no mundo digital: assinaturas! 
Uma autoridade certificadora (CA - Certificate Authority) é um órgão que garante ao navegador e ao usuário que a identidade de um servidor (por exemplo o servidor da Alura) é realmente válida. Portanto, podemos trocar informações com este sem riscos!
Para Saber Mais: As chaves do HTTPS
Aprendemos no vídeo que o HTTPS usa uma chave pública e uma chave privada. As chaves estão ligadas matematicamente, o que foi cifrado pela chave pública só pode ser decifrado pela chave privada. Isso garante que os dados cifrados pelo navegador (chave pública) só podem ser lidos pelo servidor (chave privada). Como temos duas chaves diferentes envolvidas, esse método de criptografia é chamado de criptografia assimétrica. No entanto, a criptografia assimétrica tem um problema, ela é lenta.
Por outro lado, temos a criptografia simétrica, que usa a mesma chave para cifrar e decifrar os dados, como na vida real, onde usamos a mesma chave para abrir e fechar a porta. A criptografia simétrica é muito mais rápida.
Agora, o interessante é que o HTTPS usa ambos os métodos de criptografia, assimétrica e simétrica. Como assim? Muita calma, tudo o que aprendemos é verdade! Só faltou o grande final 
No certificado, vem a chave pública para o cliente utilizar, certo? E o servidor continua na posse da chave privada, ok? Isso é seguro, mas lento e por isso o cliente gera uma chave simétrica ao vivo. Uma chave só para ele e o servidor com o qual está se comunicando naquele momento! Essa chave exclusiva (e simétrica) é então enviada para o servidor utilizando a criptografia assimétrica (chave privada e pública) e então é utilizada para o restante da comunicação.
Então, HTTPS começa com criptografia assimétrica para depois mudar para criptografia simétrica. Essa chave simétrica será gerada no início da comunicação e será reaproveitada nas requisições seguintes. Bem-vindo ao mundo fantástico do HTTPS
O que você aprendeu nesse capítulo?
· Por padrão, os dados são trafegados como texto puro na web.
· Apenas com HTTPS a Web é segura
· O protocolo HTTPS nada mais é do que o protocolo HTTP mais uma camada adicional de segurança, a TLS/SSL
· O tipo de criptografia de chave pública/chave privada
· O que são os certificados digitais
· Certificados possuem identidade e validade
· As chaves públicas estão no certificado, a chave privada fica apenas no servidor
· O que é uma autoridade certificadora
· O navegador utiliza a chave pública para criptografar os dados
Parte inferior do formulário
MÓDULO 03 – ENDEREÇOS SOB SEU DOMÍNIO
Você que está usando a Alura, já conhece então o endereço: https://www.alura.com.br. Já sabemos que o endereço começa com http ou https. Repare que depois do nome do protocolo vem :// seguido pelo nome do site, que é www.alura.com.br. No vocabulário de um desenvolvedor o www.alura.com.br é o domínio (ou domain). A abreviação www representa o world wide web.
Analisando o domínio
Vamos dar uma olhada com mais carinho no nome do domínio. Olhando da direita para a esquerda, o domínio começa com br, indicando um site do Brasil. O br representa o top level domain, está na raiz do domínio. Depois vem o com, abreviação de comercial e alura. O com e o alura são sub-domínios. O domínio é o nome do site na Web. Ele facilita a navegação do usuário, que não precisa lembrar o IP de cada site.
O www representa também um sub-domínio, no entanto seu uso é opcional, tanto que alura.com.br e www.alura.com.br funcionam e mostram a mesma página. A maioria dos site usam o prefixo www e podemos dizer que isso é algo legado que continua ser popular apesar de não ser necessário.
Subdomínios
Existe também a ideia de subdomínios, que representam sessões específicas dentro de um site. Por exemplo, no caso do Gmail temos o endereço: mail.google.com , ou ainda no caso do Google Drive: drive.google.com. Tanto Gmail como Drive são subdomínios do domínio Google.
Perceba que esses subdomínios apontam para páginas diferentes dentro do mesmo domínio (Google).
Endereços IP's
O nome do domínio é organizado em uma hierarquia que foi criada para organizar os sites na internet e para a gente ter algo fácil para se lembrar. Para ser correto, a internet funciona na verdade sem esses domínios. Aqueles nomes são coisas dos humanos, as máquinas na internet têm uma outra forma de se endereçar. Elas usam o que se chama endereços de IP, que nada mais são do que números - muito difícil para a gente decorar.
Sendo assim, podemos acessar o Google usando um IP. Para quem é muito curioso, mas muito curioso mesmo e deseja saber qual é o IP do Google, pode digitar na linha de comando a seguinte instrução:
nslookup google.com
...
Name: google.com
Address: 216.58.202.238
Esse comando procura o número IP do Google na internet. Podemos até usar esse endereço no navegador: http://216.58.202.238
A página principal do Google deve ser exibida. IP's são mais importantes para quem trabalha com rede. O desenvolvedor normalmente não precisa mexer com isso.
Observação: Esse IP pode mudar dependendo do servidor concreto onde o Google foi instalado.
DNS
Mas a gente não acessa a Google ou a Alura por um número como 52.206.164.173 e sim pela URL.
Ainda bem, não é verdade? Seria inviável decorar todos os serviços e sites que acessamos diariamente apenas por números.
Acontece que por baixo dos panos quando realizamos uma requisição essa URL é transformada em um número por um serviço transparentechamado de DNS (D*omain *Name System).
Esse serviço age como um grande banco de dados de domínios. Portanto quando fazemos uma requisição para alura.com.br o DNS age transformando para um IP e a requisição prossegue. O DNS realiza a tradução do nome de um domínio para o endereço de IP. Existem vários servidores DNS no mundo e é fundamental para a nossa web o funcionamento deles.
Podemos inclusive escolher um servidor DNS de preferência na nossa internet. Um bastante usado é o da própria Google: https://developers.google.com/speed/public-dns/
Como já falamos, quando usamos a URL https://www.alura.com.br abrimos uma conexão com o servidor que roda em algum lugar na internet. Para estabelecer uma conexão na rede é preciso saber qual é o endereço IP, e já vimos como descobri-lo.
Agora imagine que o servidor é uma casa: dependendo da casa há várias portas disponíveis. O que é preciso saber é qual porta devemos utilizar quando chegarmos na casa. Ou seja, devemos saber qual porta é utilizada para o protocolo HTTP!
Abrindo portas
A porta reservada para o protocolo HTTP é o 80. Novamente um número, e como o navegador já sabe essa porta padrão, podemos omiti-la, mas nada nos impede adicioná-la no endereço, por exemplo:
http://www.alura.com.br:80
Vai funcionar normalmente, tanto que o navegador esconde automaticamente :80. Vamos tentar uma outra porta, outro número, por exemplo 81:
http://www.alura.com.br:81
Não funciona, pois essa porta não está aberta no servidor, não podemos estabelecer uma conexão e o tempo de conexão vai esgotar. Igualmente, o protocolo HTTPS possui uma porta padrão, a porta 443, que também podemos omitir ao acessarmos um endereço HTTPS. Podemos testar também e ver que funciona normalmente.
https://www.alura.com.br:443
Navegando dentro da Alura, mais informações aparecem depois do nome e do domínio. Por exemplo, para acessar a página principal dos cursos, usamos https://cursos.alura.com.br/dashboard. O /dashboard é um recurso (resource) do site que gostaríamos de acessar. Existem vários outros recursos na Alura como as carreiras (/careers), ou o fórum de discussões (/forum). O importante é que cada recurso possua o seu nome único.
Navegando um pouco mais na Alura, podemos perceber que entre o domínio e o recurso podem vir outras informações . Por exemplo, para acessar o curso HTML5 e CSS3 I: Suas primeiras páginas da Web, usamos https://cursos.alura.com.br/course/introducao-html-css. Ou seja, para acessarmos o recurso /introducao-html-css, usamos um caminho intermediário, o /course. Há vários outros exemplos na Alura que usam caminhos para chegar ao recurso concreto, como por exemplo /courses/mine, e navegando na Alura você encontrará mais.
Finalmente, a URL
Repare que estamos usando umas regras bem definidas para descrever a localização de um recurso na web. Todos os endereços na web sempre seguem esse mesmo padrão: protocolo://dominio:porta/caminho/recurso. Esse padrão, na verdade, segue uma especificação que foi batizada de Uniform Resource Locator, abreviada como URL. Então, as URLs são os endereços na web!
Para saber mais: URI ou URL?
Muitas vezes, desenvolvedores usam a sigla URI (Uniform Resource Identifier) quando falam de endereços na web. Alguns preferem URL (Uniform Resource Locator), e alguns misturam as duas siglas à vontade. Há uma certa confusão no mercado a respeito e mesmo desenvolvedores experientes não sabem explicar a diferença. Então, qual é a diferença?
Resposta 1 (fácil): Uma URL é uma URI. No contexto do desenvolvimento web, ambas as siglas são válidas para falar de endereços na web. As siglas são praticamente sinônimos e são utilizadas dessa forma.
Resposta 2 (mais elaborada): Uma URL é uma URI, mas nem todas as URI's são URL's! Existem URI's que identificam um recurso sem definir o endereço, nem o protocolo. Em outras palavras, uma URL representa uma identificação de um recurso (URI) através do endereço, mas nem todas as identificações são URL's.
Humm ... ficou claro? Não? Vamos dar um exemplo! Existe um outro padrão que se chama URN (Uniform Resource Name). Agora adivinha, os URN's também são URI's! Um URN segue também uma sintaxe bem definida, algo assim urn:cursos:alura:course:introducao-html-css. Repare que criamos uma outra identificação do curso Introdução ao HTML e CSS da Alura, mas essa identificação não é um endereço.
Novamente, a resposta 2 vai muito além do que você realmente precisa no dia a dia. Normalmente URL e URI são usados como sinônimos.
O que aprendemos nesse capítulo?
· URL são os endereços da Web
· Uma URL começa com o protocolo (por exemplo https://) seguido pelo domínio (www.alura.com.br)
· Depois do domínio pode vir a porta, se não for definida é utilizada a porta padrão desse protocolo
· Após o domínio:porta, é especificado o caminho para um recurso (/course/introducao-html-css)
· Um recurso é algo concreto na aplicação que queremos acessar
MÓDULO 04 – O CLIENTE PEDE E O SERVIDOR RESPONDE
 Já descobrimos que o HTTP é um protocolo que define as regras de comunicação entre cliente e servidor e de que as URLs são constituídas. Porém isso não é tudo, vejamos mais alguns detalhes sobre o funcionameto da Web e do HTTP.
Realizaremos um teste efetuando login na Alura. Quando preenchemos o formulário e clicamos no botão, o navegador envia o nosso login e a nossa senha para o servidor através do protocolo HTTP! Vamos detalhar um pouco esta ação.
No mundo HTTP, a requisição enviada pelo navegador para o servidor é chamada de HTTP REQUEST. Recebemos a página /dashboard como resposta já que enviamos login e senha válidos. No mundo HTTP essa resposta é chamada de HTTP RESPONSE.
A comunicação segue sempre esse modelo: o cliente envia uma requisição e o servidor responde. Requisição e Resposta ou em inglês: Request-Response. Aqui é importante saber que a comunicação sempre começa com o cliente: é ele quem pede as informações. O servidor responde apenas o que foi requisitado e nunca inicia a comunicação!
Comunicação sem estado
Vamos acessar rapidamente outro site: http://g1.globo.com. Para este acesso estamos enviando uma requisição para g1 e recebemos como resposta a página inicial.
Agora vamos navegar dentro do site e acessar algum artigo. Ao clicarmos enviamos uma nova requisição e percebemos que TODA página foi trocada. Fica mais claro ainda se acessarmos do menu acima algum link (globo esporte ou globo show). Podemos ver que todo o conteúdo do site foi trocado.
Isso também acontece no caso da Alura (talvez um pouco mais difícil de perceber). Ao acessarmos recursos diferentes todo o conteúdo no navegador foi trocado (apesar do menu parecer o mesmo, ele também foi trocado). A ideia do HTTP é justamente essa, cada recurso é independente do outro e não depende do anterior. Isso também se aplica para os dados enviados na requisição. Cada requisição é independente da outra e ela sempre deve conter todas informações para o servidor responder.
Pense que HTTP funciona como o envio de cartas pelo correio e uma carta representa uma requisição. Você fez uma viagem e gostaria de enviar 3 cartas para sua mãe. Adianta falar para os correios "eu vou colocar o endereço apenas na primeira carta, ai vocês já sabem para onde enviar a segunda e terceira carta"? Não adianta pois os correios tratam cada carta independentemente, e assim também funciona o HTTP. Cada requisição (carta) precisa ter todas as informações. A mesma coisa se aplica para a resposta, precisa ter todas as informações.
Essa característica de cada requisição ser independente é chamada de stateless. É esse nome bonito mesmo! O HTTP é um protocolo que não mantém o estado de requisições. Isso significa que só com HTTP não há como se lembrar das requisições anteriores enviadas para o servidor. Por isso precisamos incluir em cada requisição todas as informações, sempre. Para o desenvolvedor este conhecimento é importante pois é justamente essa característica stateless que o atrapalha no dia a dia. Ele precisa preparar a aplicação web para que funcione bem usando o protocolo HTTP, algo que veremosnos treinamentos da Alura.
Lidando com Sessões
Reparem que, mesmo após termos realizado o login e termos enviado várias requisições, aparece o ícone com a minha imagem no menu principal.
Ou seja, a Alura se lembra de alguma forma que eu fiz login em alguma requisição anterior. Como falamos antes, cada requisição deve enviar todas as informações para gerar a resposta. Isso significa que o navegador envia em cada requisição informações sobre o meu usuário! Se cada requisição for independente uma da outra, e não tiver como se lembrar das requisições anteriores, não tem outra explicação a não ser que o navegador envie os dados sobre o meu usuário em cada requisição! Lembre-se da carta postal, ela sempre precisa ter os dados do remetente e aqui não é diferente!
Então o navegador envia o login e senha em cada requisição? Não, não seria muito elegante nem seguro fazer isso. Mas ele faz algo parecido, acreditem ou não. Quando efetuamos o login, a Alura valida os nossos dados, certo? Nesse momento, o servidor tem certeza que o usuário existe e gera uma identificação quase aleatória para o usuário. Essa identificação é um número criado ao vivo e muito difícil de adivinhar. Esse número é a identificação temporária do usuário e ele será devolvido na resposta.
Conhecendo cookies
Então onde está esse número? O navegador grava esse número em um arquivo especial para cada site, são os famosos cookies. Como acessar esse cookie depende um pouco do navegador em uso. O mais importante é entender o porquê da existência desse número e onde ele foi gravado.
No Chrome podemos ver todos os cookies armazenados nas Configurações -> Privacidade -> Configurações de conteúdo... -> Todos os cookies e dados de site.... Se procurarmos por Alura, em cursos.alura.com.br, lá temos um cookie com o nome caelum.login.token, que contém o número da identificação. Se apagarmos esse cookie, perderemos nossa identificação, sendo assim, a Alura exigirá um novo login pois não saberá que já tínhamos logado.
Normalmente o nome do cookie é algo como session-id, dependendo da plataforma de desenvolvimento utilizada ele pode se chamar de PHPSESSID ou ASP.NET_SessionId ou JSESSIONID ou outro nome que foi inventado! O Cookie será gerado de forma transparente pela tecnologia que você for utilizar para criar aplicativos web. Esse nome, PHPSESSIONID, JSESSIONID ou outro, é gerado pela ferramenta de gerenciamento de Sessão. Por isso ela muda o nome. Se você está usando PHP, então o PHP gerará o nome do Cookie e seu identificador (número aleatório) e chamará o cookie PHPSESSIONID. No Java já será usado o nome JSESSIONID.
Resumindo, todas as plataformas ajudam a gerar esse número e a criar o cookie de maneira transparente. É dessa forma que as plataformas gerenciam as SESSÕES com o usuário. Como isso funciona de modo concreto você aprenderá nos cursos e carreiras específicas.
A ideia de manter dados entre requisições é algo muito comum no desenvolvimento de aplicações na web. Um usuário que se loga no sistema web causa a criação de uma sessão. Uma sessão então é útil para guardar informações sobre o usuário e ações dele. Um exemplo clássico é um carrinho de compras. Entre várias requisições estamos usando o mesmo carrinho de compras que guarda os nossos produtos escolhidos (fizemos uma sessão de compras online).
Uma requisição sempre deve ser enviada com todas as informações necessárias, o que faz uma requisição ser sempre independente das demais.
Uma sessão HTTP nada mais é que um tempo que o cliente permanece ativo no sistema! Isso é parecido com uma sessão no cinema. Uma sessão, nesse contexto, é o tempo que o cliente usa a sala no cinema para assistir a um filme. Quando você sai da sala, termina a sessão. Ou seja, quando você se desloga, a Alura termina a sua sessão.
Resumindo teremos:
· O HTTP usa sessões para salvar informações do usuário
· Sessões só são possíveis por uso de Cookies
· Cookies são pequenos arquivos que guardam informações no navegador
· O HTTP é stateless, não mantem estado.
O que é um cookie?
Quando falamos de Cookies na verdade queremos dizer Cookies HTTP ou Cookie web. Um cookie é um pequeno arquivo de texto, normalmente criado pela aplicação web, para guardar algumas informações sobre usuário no navegador. Quais são essas informações depende um pouco da aplicação. Pode ser que fique gravado alguma preferência do usuário. Ou algumas informações sobre as compras na loja virtual ou, como vimos no vídeo, a identificação do usuário. Isso depende da utilidade para a aplicação web.
Um cookie pode ser manipulado e até apagado pelo navegador e, quando for salvo no navegador, fica associado com um domínio. Ou seja, podemos ter um cookie para www.alura.com.br, e outro para www.caelum.com.br. Aliás, um site ou web app pode ter vários cookies!
Podemos visualizar os cookies salvos utilizando o navegador. Como visualizar, depende um pouco do navegador em questão:
No Chrome: Configurações -> Privacidade -> Configurações de conteúdo... -> Todos os cookies e dados de site... -> Pesquisar alura
No Firefox: Preferências -> Privacidade -> remover cookies individualmente -> Pesquisar alura
Login e Senha
Quando estamos autenticados em algum sistema, como a Alura, é necessário sempre enviar o e-mail e senha a cada requisição? Quando enviamos uma requisição HTTP, todos os dados para que ela seja respondida devem ser enviados. Mas e o e-mail e a senha? Quando o login é feito, a Alura tem certeza de que um usuário existe e gera uma identificação quase aleatória pra esse usuário, lembra? E esse número fica salvo em um arquivo especial, chamado cookie, que é gerado e enviado por cada site 
É importante lembrarmos que a comunicação sempre começa com o cliente: é ele quem pede as informações. O servidor responde apenas o que foi requisitado e nunca inicia a comunicação No HTTP: Request -> espera -> Resposta
O que você aprendeu nesse capítulo?
· O protocolo HTTP segue o modelo Requisição-Resposta
· Sempre o cliente inicia a comunicação
· Uma requisição precisa ter todas as informações para o servidor gerar a resposta
· HTTP é stateless, não mantém informações entre requisições
· As plataformas de desenvolvimento usam sessões para guardar informações entre requisições
MÓDULO 05 – DEPURANDO A REQUISIÇÃO HTTP
Vamos fazer um teste e usar o navegador para mostrar mais detalhes sobre a comunicação HTTP. Os navegadores mais populares como Google Chrome, Mozilla Firefox ou Microsoft Edge possuem ferramentas e plugins que visualizam como o navegador trabalha e usa o HTTP.
Para habilitar as ferramentas do desenvolvedor no Chrome vá ao menu à direita (as reticências na vertical): Mais ferramentas -> Ferramentas do desenvolvedor, ou no menu superior: Ferramentas -> Ferramentas do desenvolvedor. Após isso, selecionamos a aba Network.
No Firefox vá ao menu superior: Ferramentas -> Desenvolvedor web -> Exibir/Ocultar ferramentas.
Para o Internet Explorer aperte a tecla F12 para abrir o console do desenvolvedor e selecione a aba Rede (ou Network).
Método GET do HTTP
Vamos abrir o console de desenvolvedor e acessar o http://www.alura.com.br. Aqui usaremos o navegador Chrome, mas nos outros navegadores o comportamento é bem parecido.
No console podemos ver todas as requisições HTTP executadas pelo Chrome. Mas não só isso, também aparecem alguns códigos e métodos, além do tempo de execução para cada requisição. Repare que chamamos apenas o http://www.alura.com.br, mas foram feitas várias outras requisições em seguida.
Na primeira coluna aparece a URL (o endereço) e na segunda coluna o método HTTP. O método HTTP indica qual é a intenção ou ação dessa requisição. Enviamos uma requisição com o método GET. Queremos receber informações, sem modificar algo no servidor, que é justamente a ideia do método GET.
Primeiro código da resposta
Como resposta recebemos o código de status 301. O protocolo HTTP define alguns códigos padrões para esclarecer a resposta. Indo com o mouse em cima do 301 o Chrome mostra o significado desse código: Moved Permanently. Ouseja, o site Alura foi movido para outro lugar! Eis a questão: Onde então está o site Alura?
A localização ou a URL concreta está na resposta HTTP. Vamos clicar em cima do código de status 301 para receber mais informações. Aqui o Chrome mostra todos os cabeçalhos da requisição e da resposta. São muitos (nem tantos) mas o que nos interessa é a nova localização do site. Dentro do item Response Headers podemos ver todos os cabeçalhos que o servidor devolveu e logo logo apareceu um com o nome Location. Esse cabeçalho indica a nova URL, só que agora usando https.
Quando o navegador recebe o status 301 ele já sabe que é preciso enviar uma nova requisição e procura a nova URL no cabeçalho de resposta Location.
Redirecionando entre sites
Se alguém acessa a Alura usando http (lembrando, inseguro) automaticamente é chamado o site seguro (https). Isto é um comportamento muito comum para garantir que usamos https sempre. Se esquecermos de usar https, o servidor devolve o status 301 com a nova localização, mas agora usando https.
O navegador, ao receber 301, chama automaticamente a nova URL. No mundo de desenvolvimento web este comportamento é chamado de Redirecionamento pelo navegador, ou Redirecionamento no lado do cliente. Fomos redirecionados para o recurso correto. A tarefa do desenvolvedor é definir o código de resposta e, no caso em que algum recurso tenha mudado a URL, o código 301 será usado com o cabeçalho Location.
O código 200
Continuando no console, a segunda requisição foi para https://www.alura.com.br, novamente usando o método HTTP GET com a intenção de receber dados. Agora o código de resposta foi 200. Este é um dos códigos mais comuns e significa que tudo deu certo! Dessa vez não foi preciso fazer um redirecionamento (não tem o cabeçalho Location na resposta) e não deu nenhum outro problema. A requisição foi aceita e processada corretamente - código 200. Perfeito.
Tipos de dados diferentes
No console podemos ver que aparecem mais requisições (cada linha representa um novo request). Quando o servidor Alura devolve a resposta para o navegador vem o conteúdo da página inicial em um formato especial, chamado de HTML. O HTML define a estrutura da nossa página, define os menus, botões, links, rodapé etc. Mas dentro do HTML não vêm as imagens e outros arquivos necessários para deixar o site perfeito. Dentro dele vem apenas a URL (endereço) desses outros recursos.
Então, ao receber o HTML, o navegador dispara várias outras requisições para carregar as imagens, fontes e outros dados. Como também são requisições HTTP, o console mostra suas informações. Podemos ver que na resposta vem o tipo do conteúdo, por exemplo text/html, text/css, image/svg+xml, entre outros.
O importante é saber que o protocolo HTTP não está preso em algum formato específico. Podemos trafegar qualquer informação com ele, seja texto ou binário!
Analisando Request e Response
PRÓXIMA ATIVIDADE
· 
· 
Abaixo há um exemplo de uma requisição e resposta, usando a ferramenta telnet. Através dele, acessamos www.caelum.com.br na porta padrão 80.
O telnet estabelece apenas uma conexão TCP (protocolo de rede que roda abaixo do HTTP) e permite que enviemos dados em cima dessa conexão, através do terminal. Uma vez a conexão estabelecida, basta escrever no terminal e os dados serão enviados automaticamente para o servidor. Para o servidor realmente entender os dados, devemos respeitar a sintaxe do protocolo HTTP!
Nesse exemplo digitamos no terminal:
GET / HTTP/1.1
HOST: www.caelum.com.br
E a resposta do servidor segue logo abaixo:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding,User-Agent
Content-Language: pt-br
Date: Mon, 01 Jun 2015 21:00:20 GMT
Server: Google Frontend
Cache-Control: private
Agora, baseado nesses dados, qual foi o método HTTP e código da resposta?
O método HTTP é GET e o código da resposta é 200. Lembrando que o método define a ação ou intenção da requisição HTTP (GET é igual a receber). O código da resposta dá uma dica ao cliente se a requisição foi um sucesso ou não, e qual foi o problema em caso de falha. O código 200 significa que tudo deu certo!
Vamos fazer um teste e acessar um recurso que não existe, por exemplo: https://www.alura.com.br/nao-existe. Bom, a Alura mostra uma imagem que indica que não achou o que procuramos, mas vamos dar uma olhada no console. Repare que o código agora é 404. No mundo HTTP 404 significa que o servidor não encontrou o recurso (Not Found).
Durante o desenvolvimento de uma aplicação web podem acontecer problemas no lado do servidor. Isto é normal pois alguma lógica pode falhar, erros acontecem no desenvolvimento! A notícia boa é que o protocolo HTTP vem preparado para isso. Quando algum problema no servidor acontecer, podemos avisar o cliente através do protocolo HTTP. O código mais comum para este tipo de problema é o 500 que significa: "deu pau no servidor :)". Talvez um ou outro aluno já tenha visto um erro 500 na Alura. Isso não deveria acontecer, mas onde há humanos também há problemas, não é mesmo?
Categorias de códigos
Existem muitos códigos de resposta definidos no protocolo HTTP. Há tabelas disponíveis na web que mostram esses códigos, descrevendo o significado de cada um deles. No entanto, no dia a dia, o desenvolvedor não precisa decorar todos esses códigos. Basta consultar quando for necessário, por exemplo aqui.
O importante é saber que algo que começa com 2xx significa coisa boa, a requisição foi executada com sucesso. Quando recebemos algo como 3xx normalmente significa que o navegador precisa fazer algo a mais (o cliente precisa agir) pois algo mudou ou um recurso não existe mais. 4xx significa que o navegador enviou dados errados, como por exemplo uma URL errada. Caso o servidor gere algum problema, serão utilizados os códigos 5xx.
No dia a dia os códigos 200, 404 e 500 são de longe os mais utilizados!
Nesse capítulo, trabalhamos com depuração de uma requisição HTTP, vimos que ela pode ser feita somente com recursos do próprio browser, através do console de depuração.
Vimos também que existem métodos quando fazemos uma requisição, por enquanto só trabalhamos com método HTTP GET, que é utilizado quando estamos pedindo alguma coisa, quando queremos receber algo.
Além disso, quando recebemos uma resposta, ela contém cabeçalhos, como Location.
Por último, vimos os códigos de resposta HTTP, como 200, 301, 404 e 500, para analisar de fato o que aconteceu com a nossa requisição.
Para saber mais: Mais códigos HTTP
HTTP é o protocolo mais utilizado na internet e há muita documentação disponível. Segue um link que explica os códigos HTTP de forma divertida: httpstatusdogs ou se você preferir gatos httpcats, https://www.w3schools.com/tags/ref_httpmessages.asp, https://www.webfx.com/web-development/glossary/http-status-codes/
MÓDULO 06 – PARÂMETROS DS REQUISIÇÃO
No capítulo anterior vimos que ao efetuar uma requisição do tipo GET para http://www.alura.com.br recebíamos do servidor uma resposta de status code 301 e nessa resposta estava especificado o cabeçalho Location = https://www.alura.com.br.
Já vimos que esse código 301 indica para quem fez a requisição, no nosso caso o browser, que ele deve fazer um redirecionamento para o endereço especificado no cabeçalho Location da resposta, ou seja, para a página com HTTPS.
Ao realizar uma nova requisição para o novo endereço recebemos a indicação que deu tudo certo com a requisição através do status code 200 e no corpo da resposta o conteúdo, HTML, a ser renderizado pelo browser. Lembrando que, no HTML há dependências para outros recursos como imagens, arquivos de estilo etc, isso faz com que várias outras requisições e respostas sejam realizadas para que a página seja renderizada corretamente pelo cliente navegador.
Identificamos assim que o status code do HTTP tem uma forte relação com o que aconteceu no processamento do pedido. Podíamos inclusive catalogá-los como a seguir:
· 2XX -> Respostas de sucesso
· 3XX -> Mensagem de redirecionamento
· 4XX -> Respostas de erro do cliente
· 5XX -> Respostas de errodo servidor
Vamos ver um outro exemplo de uma URL e acessar http://www.youtube.com. Como tem muito conteúdo no YouTube, vamos pesquisar, por exemplo por Ayrton Senna. Repare que, ao pesquisar no YouTube, a URL mudou um pouco. O recurso acessado pela busca se chama /results (os resultados da pesquisa) mas agora temos um parâmetro da requisição, indicado pela ?: https://www.youtube.com/results?search_query=Ayrton+Senna
O parâmetro se chama search_query com o valor Ayrton+Senna. Esses parâmetros da URL normalmente são chamados de Query Params. O HTTP permite enviar mais de um parâmetro, basta concatenar o próximo parâmetro através do caractere &.
Por exemplo, a busca avançada do Google usa vários parâmetros para refinar a pesquisa como o idioma, o país ou data. Veja como o Google concatena os Query Params: https://www.google.com.br/?gws_rd=ssl#lr=lang_pt&tbs=lr:lang_1pt&q=neymar
Parâmetros com GET
Reparem que no console sempre aparece o tipo (ou método) da requisição, sendo GET. Uma característica da requisição GET é enviar os parâmetros pela URL! Isso é útil quando queremos deixar os parâmetros visíveis. Assim podemos facilmente guardar a URL com os parâmetros para repetir a requisição algum momento depois. Mas será que isso também é uma boa opção na hora de enviar credenciais como login e senha? Queremos que apareça a senha de um usuário na URL?
Imagina que você efetue o login no seu banco e na URL apareça: https://www.bb.com.br/login?login=nico&password=supersecreto
Não parece ser uma boa solução, não é mesmo?
O método HTTP POST
Vamos efetuar um login na Alura para ver como esse sistema envia dados do usuário para o servidor.
log no console das requisição ao fazer login na alura
Repare que a URL para enviar o login e senha se chama https://www.alura.com.br/signin. Repare também que o método HTTP utilizado mudou. Estamos usando o HTTP POST! Usando o POST, o navegador envia os dados do formulário no corpo da requisição e não na URL! Se fosse um GET, todos os dados seriam enviados através da URL. Como a Alura não deseja que os dados do login e senha apareçam na URL do navegador, foi utilizado um HTTP POST. Faz sentido?
GET para receber, POST para criar?
Um outro exemplo de um método POST na Alura é quando criamos uma pergunta no forum. Nesse momento o usuário submete um formulário com dados para criar um novo recurso na Alura (a pergunta do aluno se torna um recurso). O método POST foi inicialmente pensado para criar algo novo no servidor como acabamos de fazer. Ou seja, ao enviar uma requisição POST para o servidor, a nossa intenção é criar algo novo. No entanto, nem sempre isso é realmente utilizado dessa maneira. Por exemplo, acabamos de usar um POST para verificar o login, ou seja, não alteramos ou adicionamos nada na Alura. Nossa motivação para o POST era esconder os parâmetros apenas.
Como o servidor realmente reage quando recebe uma requisição POST depende da implementação, depende da lógica atrás. Os métodos como GET e POST definem uma intenção mas o que realmente será executado depende do servidor.
No dia a dia, vocês vão ver códigos usando GET para fazer pesquisas mas também para alterar ou remover algo no servidor. A mesma coisa podemos dizer sobre POST. Vocês vão usar o POST para inserir e alterar dados, mas também para pesquisar. As aplicações podem adaptar o significado dos métodos HTTP quando for necessário.
Para saber mais: Parâmetros na URL 
Como, por exemplo, podemos enviar uma requisição usando o método GET para carregarmos a página que exibe informações sobre o usuário de número 2. Devemos passar o parâmetro id com o valor 2. Como por exemplo:
http://meusite.com.br/usuario?id=2
Uma outra forma de fazer seria passar os valores na própria URL! Veja o exemplo:
http://meusite.com.br/usuario/2
Mas tem um probleminha, não estamos dizendo explicitamente que o valor 2 realmente representa o id. Quando um parâmetro irá receber um certo valor, devemos combinar com o servidor (com o desenvolvedor da aplicação). Neste caso, foi combinado que o parâmetro recebido seria equivalente ao id passado antes.
Vamos ver um exemplo prático, em um serviço que retorna informações sobre um endereço de um determinado CEP? Acesse a URL: http://viacep.com.br/ws/20040030/json
A resposta será todas as informações do CEP da Caelum Rio, como complemento, número e bairro, formatadas em JSON. Isso significa que foi combinado com o servidor, que o primeiro valor passado depois de ws deve ser o CEP e logo após, o formato em que os dados deverão chegar. No nosso caso, JSON. Tudo bem? :)
Experimente agora trocar para o CEP de sua casa e para outro formato de dados, como por exemplo, XML.
Para saber mais: Outros métodos HTTP e Web Services
Já falamos bastante sobre os métodos (ou verbos) HTTP, GET e POST. Esses dois são utilizados na grande maioria das aplicações web, e fazem parte do dia a dia do desenvolvedor, no entanto existem diversos outros métodos.
Se o GET foi criado para receber dados, e o POST para adicionar algo no servidor, será que não existe algo para apagar e atualizar?
A resposta é sim, e os métodos se chamam DELETE e PUT.
Novamente esses métodos normalmente não são utilizados quando se trata de uma aplicação web, e são mais importantes quando o assunto é Web Services.
Agora vem a pergunta, você já ouviu falar de Web Services?
Quando falamos de um Web Service, sempre usamos o protocolo da web, ou seja o HTTP.
Um Web Service disponibiliza uma funcionalidade na web, através do protocolo HTTP. As funcionalidades variam muito e dependem muito da empresa e do negócio dela, mas por exemplo, na Alura temos um Web Service que traz todas as informações de um curso (nome, capítulos, exercícios, etc). O Google ou Facebook possuem muitos Web Services para acessar um usuário, ver os posts dele, interesses, etc. Muitas vezes esses serviços são pagos.
O importante é que sempre usamos o protocolo HTTP. A grande diferença de um Web Service é que os dados não vem no formato HTML, e sim em algum formato independente da visualização, como XML ou JSON.
Vimos o uso e as diferenças básicas entre os métodos GET e POST, que resumindo são: GET é utilizado para a busca de informações e tem seus parâmetros listados na URL, indicados pela presença da interrogação (?) seguido de pares de chave e valor, lembrando que vários parâmetros podem ser enviados simplesmente concatenando-os com o caractere &. Exemplo: https://www.youtube.com/results?search_query=ayrton+senna&sp=cam%250
O POST por outro lado é mais utilizado para criação de recursos, informações no servidor e envia seus dados no corpo da requisição.
Para finalizar o capítulo, mencionamos que existem outros métodos HTTP como o DELETE e PUT (e acredite que tem mais ainda). O DELETE existe para enviar uma requisição com a intenção de remover um recurso, PUT para atualizar. No entanto, esses métodos são poucos utilizados no desenvolvimento de aplicações web, eles são mais importantes quando se tratam de serviços web.
Em geral, há mais recursos que o protocolo HTTP oferece, como vários outros cabeçalhos que especificam mais a requisição e resposta. Aqui nesse treinamento vimos os mais importantes métodos, códigos e cabeçalhos do protocolo HTTP.
MÓDULO 07 – SERVIÇOS NA WEB COM REST
Já estudamos como o modelo de requisição-resposta funciona usando o browser para esse estudo. Mas será que toda a requisição HTTP sempre tem como origem um navegador? E toda resposta só possui conteúdo que ele entende: HTML, CSS, Javascript e imagens?
Nesse capítulo veremos como as aplicações conseguem se comunicar e responder as questões levantadas anteriormente.
##Serviços WEB
Hoje existem milhões de softwares rodando ou sendo desenvolvidos em várias linguagens de programação e frameworks. Tais softwares não vivem necessariamente isolados e podem querer se comunicar de alguma forma.
Um exemplo clássico é o login via rede social que estamos cada vez mais habituados. Essa conversa acaba sendo transparente para nós, usuários, já que exige uma autorização de acesso às nossas informações.
Em outros momentosas aplicações conversam sem que nada visual seja implementado ou mesmo uma autorização do cliente seja pedida.
As aplicações que disponibilizam serviços para outras são chamadas de webservices. E uma API de utilização é documentada para uma integração eficiente entre sistemas.
Temos serviços web para trabalhar com pagamentos(Paypal é um exemplo famoso), upload de imagens, transformação de CEP em endereços textuais e diversos outros. Tudo isso é feito através do poderoso protocolo HTTP.
##Cenário de trabalho
Você muito provavelmente já teve uma péssima experiência quando estava sem conexão com a internet usando um aplicativo móvel. Alguns apps não funcionam sem um acesso a rede porque as principais funcionalidades são feitas via requisições HTTP.
Essas requisições são implementadas programaticamente pelo desenvolvedor. Podemos implementá-las em várias linguagens de programação: Java, PHP, Javascript etc.
Para exemplificar vamos imaginar que temos aqui na Alura uma divisão responsável por uma aplicação de pedido de refeições que é a AluraFood.
A AluraFood tem duas equipes em ação: a do serviço web(ou simplesmente API web) e a dos apps mobile(Android e iOS).
Os desenvolvedores responsáveis pela tela de listagem de restaurantes vão precisar receber do serviço os detalhes de cada restaurante. Felizmente o pessoal responsável pelo webservice já documentou exatamente o que seria necessário:
Listagem de todos os restaurantes --> GET - http://alurafood.com/api/restaurante
Como retorno dessa requisição poderíamos receber o seguinte conteúdo HTML:
<!DOCTYPE html>
<html lang="en">
<head> 
 <meta charset="UTF-8">
 <title>AluraFood</title>
 <link rel="stylesheet" type="text/css" href="principal.css">
 <script type="text/javascript" src="build.js"></script>
</head>
<body>
 <table>
 <tr>
 <td>Bob's</td>
 <td>8</td>
 <td>R. do México 100</td>
 <td><img src="http://alurafoods.com/uploads/logos/bobs.png"/></td>
 </tr>
 <tr>
 <td>Subway</td>
 <td>8.5</td>
 <td>Av. Rio Branco 202</td>
 <td><img src="http://alurafoods.com/uploads/logos/subway.png"/></td>
 </tr>
 <tr>
 <td>Experimenta Lanches</td>
 <td>9</td>
 <td>R. do Brasil 545</td>
 <td><img src="http://alurafoods.com/uploads/logos/e-lanches.png"/></td>
 </tr>
 </table>
</body>
</html>
Perceba que temos uma listagem de restaurante sendo apresentada dentro de uma tabela(elemento table do HTML) e cada linha(elemento tr) possui 4 colunas(td). Dentro de cada coluna temos as informações dos restaurantes: nome, nota de avaliação, endereço e logo.
Logo percebemos que os responsáveis precisarão realizar uma análise do conteúdo HTML e extrair dele somente as informações necessárias. Esse ato de analisar o documento é chamado de realizar um parsing do arquivo.
Perceba que o HTML tem muito mais do que o necessário para essa equipe, é um formato de verbosidade considerável: temos cabeçalhos e tags diversas. Para piorar estamos trafegando muito mais informações do que o necessário e onerando até mesmo a banda do nosso usuário. Péssimo cenário não é mesmo?
Pensando nessa deficiência do HTML temos outros formatos que fazem mais sentido quando uma representação de um recurso (um restaurante) se faz necessário. Temos como exemplo mais legível o XML(eXtensible Markup Language) que poderia ser devolvido como resposta e ter o seguinte conteúdo:
<?xml version="1.0"?>
<restaurantes>
 <restaurante>
 <nome>Bob's</nome>
 <avaliacao>8</avaliacao>
 <endereco>R. do México 100</endereco>
 <logo>http://alurafoods.com/uploads/logos/bobs.png</logo>
 </restaurante>
 <restaurante>
 <nome>Subway</nome>
 <avaliacao>8.5</avaliacao>
 <endereco>Av. Rio Branco 202</endereco>
 <logo>http://alurafoods.com/uploads/logos/subway.png</logo>
 </restaurante>
 <restaurante>
 <nome>Experimenta Lanches</nome>
 <avaliacao>9</avaliacao>
 <endereco>R. do Brasil 545</endereco>
 <logo>http://alurafoods.com/uploads/logos/e-lanches.png</logo>
 </restaurante>
</restaurantes>
Outro famoso formato e onerando menos ainda a rede, por ser mais leve, é o JSON(JavaScript Object Notation):
[
 {
 "nome": "Bob's",
 "avaliacao": "8",
 "endereco": "R. do México 100",
 "logo": "http://alurafoods.com/uploads/logos/bobs.png"
 },
 {
 "nome": "Subway",
 "avaliacao": "8.5",
 "endereco": "Av. Rio Branco 202",
 "logo": "http://alurafoods.com/uploads/logos/subway.png"
 },
 {
 "nome": "Experimenta Lanches",
 "avaliacao": "9",
 "endereco": "R. do Brasil 545",
 "logo": "http://alurafoods.com/uploads/logos/e-lanches.png"
 }
]
Mas como especificar à aplicação de serviço que gostaríamos de receber em um formato JSON? Via cabeçalho HTTP!
Para indicar que queremos resposta no formato JSON usa-se um Accept: application/json como cabeçalho HTTP. Por outro lado já na resposta uma indicação desse conteúdo é especificado pelo cabeçalho Content-Type: application/json.
Requisições HTTP podem ser enviadas através de qualquer aplicativo/software que entenda o protocolo. O HTTP não depende do navegador. Aliás, o tempo todo o nosso celular usa o HTTP para enviar requisições através de aplicativos!
HTTP é totalmente independente do formato dos dados.
HTTP pode trafegar dados binários como imagens e dados textuais como HTML ou CSS!
O protocolo HTTP envia dados em texto puro e já estudamos sobre as implicações disso em questões de segurança. Vimos inclusive como o HTTPS lida com isso.
Em alguns momentos se faz necessário avisar na própria requisição um formato específico esperado para a resposta.
De que forma podemos especificar o formato que esperamos que seja devolvido?
A resposta correta é usando o cabeçalho Accept.
Através dele podemos usar algum formato específico como:
Accept: text/html, Accept: text/css, Accept: application/xml, Accept: application/json, Accept:image/jpeg e Accept: image/*
Ou até mesmo não definir nenhum formato específico colocando:
Accept: */*
Tudo certo para a listagem de restaurantes. Mas será que o app AluraFood se resume a listar restaurantes? Provavelmente não, dado que o usuário efetua pedidos, um restaurante tem cardápio que poderia sofrer alterações e por aí vai.
Algumas funcionalidades específicas aos responsáveis de um restaurante podem ser necessárias. E para isso o webservice deveria estar preparado também para lidar com essa necessidade:
Listagem de todos os restaurantes --> GET - /restaurante
Adicionar um restaurante --> POST - /restaurante
Perceba que no exemplo fictício as duas primeiras URIs são idênticas e a funcionalidade muda completamente a partir do método HTTP usado:
GET -> Listagem
POST -> Criação
A atualização poderia ter um outro endpoint como por exemplo:
PUT/PATCH - /restaurante/1
O número 1 ao final da URI indica um identificador a um restaurante específico.
A remoção de um restaurante poderia seguir o mesmo modelo:
DELETE - /restaurante/1
Para a busca do cardápio de um restaurante específico o endpoint gerado poderia seguir o modelo:
GET - /restaurante/1/cardapio
O padrão REST
Logo podemos perceber que o padrão usado pela equipe do webservice define que uma requisição web tem três tipos de componentes importantes: recursos (URI), operações (GET, POST, PUT, DELETE/...) e representação de dados(XML, JSON, ...).
Esses três componentes em conjuntos seguindo algumas práticas são a base para o modelo arquitetural REST(Representational State Transfer) ou em português Transferência de Estado Representacional.
Recurso
Ao criar as URIs do nosso sistema devemos levar em conta que elas representam recursos, não ações.
Em sistemas REST, nossas URIs devem conter apenas substantivos, que são nossos recursos: /restaurante/adiciona não é uma boa URI, pois contém um verbo e não está identificando um recurso, mas sim uma operação.
Para representar a adição de umrestaurante podemos usar a URI /restaurante com o método HTTP POST, que representa que estamos adicionando alguma informação no sistema.
Operações
O protocolo HTTP possui operações através de métodos como: GET, POST, PUT e DELETE.
Cada método tem uma semântica diferente e juntando o método à URI deveríamos conseguir representar todas as ações do nosso sistema.
As semânticas principais são:
· GET - recupera informações sobre o recurso identificado pela URI. Ex: listar restaurante, visualizar o restaurante 1. Uma requisição GET não deve modificar nenhum recurso do seu sistema, ou seja, não deve ter nenhum efeito colateral, você apenas recupera informações do sistema.
· POST - adiciona informações usando o recurso da URI passada. Ex: adicionar um restaurante. Pode adicionar informações a um recurso ou criar um novo recurso.
· PUT - adiciona (ou modifica) um recurso na URI passada. Ex: atualizar um restaurante.
· DELETE - remove o recurso representado pela URI passada. Ex: remover um restaurante.
Representação
Quando fazemos uma aplicação não trafegamos um recurso pela rede, apenas uma representação dele. E essa representação pode ser feita de diferentes formas como JSON, XML ou HTML.
Conclusão
Nossas URIs devem representar recursos, as operações no recurso devem ser indicadas pelos métodos HTTP e podemos falar qual é o formato em que conversamos com o servidor com o Content-Type e Accept que são cabeçalhos do HTTP.
· REST é um padrão arquitetural para comunicações entre aplicações
· Ele aproveita a estrutura do HTTP
· Recursos são definidos via URI
· Operações com métodos HTTP(GET/POST/PUT/DELETE)
· Cabeçalhos(Accept/Content-Type) são usados para especificar as representações(JSON,XML,...)
Para saber mais: tipos de dados
Em alguns cabeçalhos do HTTP devemos especificar algum formato. Os formatos são chamados na documentação de MIME types. E na definição do cabeçalho usamos a seguinte estrutura: tipo/subtipo. São tipos conhecidos:
text, image, application, audio e video
E alguns subtipos:
text -> text/plain, text/html, text/css, text/javascript
image -> image/gif, image/png, image/jpeg
audio -> audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
video -> video/mp4
application -> application/xml, application/pdf
Para conhecer outros formatos aceitos você pode acessar aqui: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
MÓDULO 08 – HTTP2 POR UMA WEB MAIS EFICIENTE
Até agora sempre usamos o browser para realizar uma requisição. Mas podemos realizar fora dele usando a linha de comando por exemplo. Um programa famoso para isso é o CURL. No Linux e MacOS ele já vem instalado por padrão.
Caso esteja usando o Windows é necessário a instalação dele. O download deve ser feito por aqui: https://curl.haxx.se/download.html
Para realizar e depurar uma requisição via CURL podemos simplesmente executar no terminal o seguinte comando:
curl -v www.caelum.com.br
Uma saída típica dele seria:
Fabios-MacBook-Pro:~ fabiopimentel$ curl -v www.caelum.com.br 
* Rebuilt URL to: www.caelum.com.br/
* Trying 172.217.29.51...
* Connected to www.caelum.com.br (172.217.29.51) port 80 (#0)
> GET / HTTP/1.1
> Host: www.caelum.com.br
> User-Agent: curl/7.49.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Vary: Accept-Encoding,User-Agent
< Content-Language: pt-br
< Content-Type: text/html;charset=UTF-8
< X-DNS-Prefetch-Control: on
< X-Cloud-Trace-Context: 3e5e270ee3ab1e79f81b10d2cdef53cd
< Date: Fri, 24 Mar 2017 19:20:12 GMT
< Server: Google Frontend
< Content-Length: 95776
< 
 <!DOCTYPE html>
 <html class="no-js"lang="pt-br"> <head> <title>Caelum | Cursos de Java, .NET, Android, PHP, Scrum, HTML, CSS e JavaScript </title>
Pode-se notar pela saída que temos logo no começo as informações do request efetuado:
> GET / HTTP/1.1
> Host: www.caelum.com.br
> User-Agent: curl/7.49.1
> Accept: */*
E após essas infos temos o cabeçalho da resposta obtida pelo servidor:
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Vary: Accept-Encoding,User-Agent
< Content-Language: pt-br
< Content-Type: text/html;charset=UTF-8
< X-DNS-Prefetch-Control: on
< X-Cloud-Trace-Context: 3e5e270ee3ab1e79f81b10d2cdef53cd
< Date: Fri, 24 Mar 2017 19:20:12 GMT
< Server: Google Frontend
< Content-Length: 95776
Logo depois vem o corpo da resposta (HTML da página requisitada):
 <!DOCTYPE html> <html class="no-js"lang="pt-br"> <head> <title>Caelum | Cursos de Java, .NET, Android, PHP, Scrum, HTML, CSS e JavaScript </title> <meta name="viewport"content="width=device-width,initial-scale=1"> <meta name="format-detection"content="telephone=no"> <meta name="referrer"content="origin"> <meta name="description"content="A Caelum tem os cursos de Java, Scrum, Web, Front-end, PHP, .NET e Mobile mais reconhecidos no mercado, com didática diferenciada e instrutores qualificados."> <link rel="canonical"href="https://www.caelum.com.br/"> <style>.calendario .sem-turmas,.calendario-compacto .mais-turmas,.fm-message.fm-warning{font-style:italic}
Em resumo o output apresentando pelo CURL possui essa divisão:
#HTTP/2
O protocolo que estamos trabalhando até agora foi especificado na década de 90 e de lá até hoje muitas alterações foram feitas até na forma como usamos a internet.
Com a chegada do mundo mobile novas preocupações apareceram e otimizações são cada vez mais necessárias para uma boa performance. Por isso uma mudança foi necessária e em 2015 depois de alguns anos de especificações e reuniões surgiu a versão 2 desse protocolo.
A nova versão é batizada de HTTP/2 e tem como página principal de documentação e referência essa: <a href="https://http2.github.io/">https://http2.github.io/</a>.
A nova versão do protocolo HTTP traz mudanças fundamentais para a Web. Recursos fantásticos que vão melhorar muito a performance da Web além de simplificar a vida dos desenvolvedores.
No HTTP 1.1, para melhorar a performance, habilitamos o GZIP no servidor para comprimir os dados das respostas. É uma excelente prática, mas que precisa ser habilitada explicitamente. No HTTP/2, o GZIP é padrão e obrigatório.
É como se a gente passasse a ter a resposta assim:
Mas, se você já olhou como funciona uma requisição HTTP, vai notar que só GZIPar as respostas resolve só metade do problema. Tanto o request quanto o response levam vários cabeçalhos (headers) que não são comprimidos no HTTP 1.1 e ainda viajam em texto puro.
Já na nova versão, os headers passam a ser binários:
Além de binários eles são comprimidos usando um algoritmo chamado HPACK. Isso diminui bastante o volume de dados trafegados nos headers.
Além de todas essas otimizações para melhorar a performance ainda houve uma preocupação com segurança exigindo TLS por padrão também.
O HTTP/2 possui diversas tecnologias de compactação de sua requisição. Isto acaba sendo muito útil para clientes móveis, visto que a maioria das redes mobile ainda não são de grande qualidade. Apesar do protocolo HTTP/1.1 ter sido de extrema importância para a Web ao longo de vários anos, como toda boa tecnologia, é necessário um update. A nova versão do HTTP veio para adequar este protocolo tão famoso a um mundo onde temos muito mais dados sendo trafegados na rede, e a velocidade de acesso e segurança do usuário se tornam bastante importantes. 
O HPACK é uma tecnologia especializada em comprimir os Headers das comunicações HTTP/2. Como toda requisição HTTP acompanha algum header por padrão, uma tecnologia de compressão embutida no protocolo é demasiadamente útil para economizar dados trafegados.
No HTTP/1.1 o Gzip não é nativo do protocolo, no HTTP/2 ele já vem por padrão.  O HTTP/2 reforça bastante o uso do HTTPS, ao contrário do HTTP/1.1 em que isto era opcional. Apesar de não ser obrigatório em sua especificação, os browsers não suportam o HTTP/2 sem HTTPS, o que acaba fazendo com que o seu uso seja exclusivo em modo criptografado.  Uma das principais mudanças é que agora no HTTP/2 os dados são trafegados em binário e não mais em texto puro.
Agora,queremos representar uma requisição. No código abaixo, estamos fazendo uma requisição através do método GET, que já conhecemos. Essa requisição está sendo feita para a raiz, bem parecido com o que fizemos no CURL no vídeo anterior.
GET /
Host: www.caelum.com.br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:34.0)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Quando realizamos uma requisição para essa URL via Firefox, por exemplo, o navegador envia alguns cabeçalhos que são padrões. Por exemplo, no cabeçalho Host, temos o domínio para onde estamos realizando essa requisição, que é www.caelum.com.br. Como estamos realizando um GET para /, o path para onde estamos realizando a requisição é www.caelum.com.br/.
Além disso, vemos uma informação de User-Agent, que é basicamente a fonte dessa requisição, neste caso é o navegador, Mozilla. Quando realizarmos uma requisição pelo CURL, aparecerá CURL, e se for num Safari, Chrome, qualquer outro navegador, irá aparecer a informação de onde estamos realizando de fato a requisição. Ou seja, nesse cabeçalho a gente especifica quem é o usuário.
Nele também é dito que é aceito, por padrão, o HTML, na linguagem tanto português quanto inglês, e que estamos aceitando uma codificação GZIP, já que no HTTP1 podemos especificar que tipo de compressão nossa requisição está aceitando.
Precisamos repetir os cabeçalhos enviados em uma requisição anterior?
Agora vamos realizar uma outra requisição, mas dessa vez para o arquivo principal.js. Então, quando a requisição para página principal foi feita, provavelmente recebemos um HTML, e desse HTML foi necessário realizar uma outra requisição, porque era um recurso importante para a página ser exibida, como por exemplo um arquivo JavaScript.
GET /principal.js
Host: www.caelum.com.br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:34.0)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Então, na próxima requisição teremos que enviar novos parâmetros, novos dados. Então, mais uma vez, é uma nova requisição, agora para /principal.js, um recurso do nosso sistema. Qual o Host? www.caelum.com.br. Qual o Agent? Mozilla, versão 5.0. O que é aceito? qual linguagem é aceita? que tipo de compressão estamos aceitando?
Podemos perceber que o que colocamos nessa segunda requisição é exatamente o mesmo que fizemos na primeira? Os mesmos dados estão sendo trafegados nas duas requisições. Seria ótimo se só trafegássemos isso uma única vez, pois se estamos enviando mais dados, oneramos ainda mais nosso usuário, usando mais banda, deixando essa requisição mais lenta.
Seria muito bom se só pudéssemos ou só tivéssemos que enviar uma única vez, e é exatamente isso que o HTTP2 faz. A partir do HTTP2, não precisamos mais repetir os Headers, os cabeçalhos que já enviamos em uma requisição anterior. Logo, quando fazemos uma requisição para o principal.js, onde teríamos os cabeçalhos exatamente iguais aos da requisição passada, nós não precisamos enviar novamente esses dados.
Cabeçalhos diferentes
Agora, se temos uma imagem, os cabeçalhos podem mudar, por exemplo, o Host, que pode estar especificado na página principal. Logo, na primeira requisição, o conteúdo HTML especificou que tem que buscar uma imagem do Host, que é image.caelum.com.br, um subdomínio dentro da nossa aplicação. Então, esse cabeçalho terá que ser alterado, logo enviaremos apenas os cabeçalhos que são diferentes.
Isso está especificado no HTTP2, para que uma requisição fique mais leve e não onere tanto o usuário. Isso é conhecido como Headers Stateful.
No início do curso, comentamos que o HTTP era stateless, ou seja, ele não guarda informações das requisições passadas. E isso continua valendo, mas no caso dos cabeçalhos, existe um ambiente que guarda estado.
Como trafegamos apenas os headers que mudam de uma requisição para outra, acabamos por economizar uma boa quantidade de dados, pois não precisamos enviar headers que mudam poucas vezes a todo momento, como o Accept, os Headers Stateful permitem que apenas os cabeçalhos que mudem sejam enviados a cada requisição, economizando muita banda que seriam cabeçalhos repetidos.
Temos o cliente e um servidor sendo representados. Podemos imaginar que estamos fazendo uma requisição para uma página principal, a index.html. Essa requisição bate no servidor e o servidor nos traz o conteúdo HTML.
O HTML retornado pode ter o título Caelum, e então vai aparecer no nosso navegador essa informação. Além disso, temos um arquivo CSS, de estilização da página, que é o estilo.css, e dois arquivos JavaScript necessários para a página ser executada, o jquery.js e o principal.js. Além disso, no meio do corpo do HTML, tem um recurso que é de imagem, temos a imagem logo.png. Mas além desses, podemos ter vários outros recursos na nossa página.
Então, ao receber esse conteúdo, o browser tem que sair fazendo requisições de tudo o que é necessário para que ele renderize a página. O navegador interpreta esse conteúdo HTML de cima pra baixo, verifica que o primeiro recurso necessário é o estilo.css, aí ele vai lá buscar. O segundo recurso necessário, jquery.js, que é uma biblioteca JavaScript. E além disso, precisamos do principal.js e do logo.png:
Todos esses recursos especificados no HTML são novas requisições que o browser precisa fazer, e nosso cliente precisa executar. O servidor vai recebendo essas requisições, mas o cliente fica ali esperando até que essas respostas cheguem e o nosso browser consiga de fato renderizar o conteúdo para o usuário. Então há uma espera até essas respostas chegarem de fato, pois o servidor devolve as respostas das requisições na mesma sequência que foram geradas.
A partir do HTTP2, isso ficou um pouco diferente. Agora temos uma conversa mais paralela. Anteriormente estávamos trabalhando com conceitos de requisições seriais, fazíamos uma requisição e esperávamos receber, fazíamos outra requisição e esperávamos receber e por aí vai. No HTTP2, quando o cliente realiza uma requisição para *index.html, o servidor devolve a página, mas ele já pode passar para o browser as informações necessárias para que essa página possa ser, de fato, exibida. Ou seja, ele consegue dar um passo além:
Isso é uma outra abordagem que surgiu no HTTP2, muito mais interessante. Mas quando o browser for interpretar essa página HTML, vai ter que passar pelo conteúdo que especifica o arquivo CSS? Sim, mas quando ele passar pelo estilo.css, vai verificar que já recebeu. Ou seja, ele percebe que já recebeu essas informações.
Este é o conceito de Server Push, ou seja, o server envia dados para o cliente sem que o cliente tenha solicitado, tornando o tráfego de dados muito mais otimizado.
O servidor pode empurrar para o clientes certos recursos antes mesmo de serem solicitados, pois ele consegue analisar o HTML e ver o que mais é preciso para carregar a página fazendo com que não seja necessário gastar tempo pedindo todos os outros recursos.
Outra coisa importante de requisição é que temos o conceito de request e response. Cada requisição e cada resposta no HTTP1.1 são únicos.
“Por baixo dos panos”, antes dessa requisição de fato ser feita, há uma conexão, comunicação entre cliente e servidor, que chamamos de TCP. Para que consigamos realizar uma requisição via HTTP, antes existe um modelo de TCP, que é um protocolo de transporte. Isso é mais a nível de infraestrutura, pois quando trabalhamos com desenvolvimento, acabamos deixando isso pra lá, já que ficamos na camada acima dessa conexão.
Queremos mostrar é que quando fazemos uma requisição, ela é única. No HTTP, cada requisição deveria abrir uma conexão TCP, executar e fechar.
Mas isso seria muito ruim porque conexão TCP é recurso caro, é um recurso que demora a ser alocado. Claro que é muito rápido a nível computacional, mas é mais um passo antes da requisiçãoHTTP prosseguir e recebermos uma resposta.
Então o que acontece, no HTTP1 existe um mecanismo chamado de Keep-Alive. O Keep-Alive determina quanto tempo, por exemplo, a nossa conexão pode ficar ativa. Ou seja, não encerra essa conexão TCP. Portanto, conseguimos realizar várias requisições com a mesma conexão TCP.
Hoje, na maioria dos browsers, temos um número entre 4 e 8 de conexões simultâneas por domínio. Significa que se fizermos uma requisição para a página da Caelum e a página da Caelum tiver mil recursos, o browser tem 4 a 8 conexões TCP ativas para conseguir realizar essas requisições em paralelo, e não serial. Mas isso na versão 1.1.
Keep-Alive no HTTP2
O Keep-Alive continua existindo no HTTP2, só que ele trouxe uma novidade. Por exemplo, se temos uma conexão TCP aberta e realizamos uma requisição, poderíamos já dar prosseguimento às próximas requisições, isso em paralelo, sem de fato ficar esperando o resultado dela, de maneira assíncrona, e vamos recebendo essas respostas à medida em que o servidor for conseguindo processar.
Na imagem abaixo, fizemos a requisição 1 e requisição 2, quando íamos fazer requisição 3, já recebemos uma resposta:
Então, essas requisições e respostas vão chegando a todo tempo. É totalmente paralelo. A mesma coisa acontece com o servidor, não precisamos esperar uma resposta para enviar outra. Se já está pronta para ser enviada, ele já envia diretamente.
Esse conceito que surgiu no HTTP2 é chamado de Multiplexing e traz uma performance bastante relevante para o nosso HTTP.
Neste capítulo, o que aprendemos? Vimos que o HTTP2 atua sobre o que já conhecemos do HTTP. Ou seja, ele não muda nada em relação ao que já conhecemos de HTTP. E que todo o seu conteúdo é usado no HTTP2 de forma bastante simples.
Hoje, o que o HTTP2 especifica é mais a nível de servidor. E acaba que nós desenvolvedores não atuamos tanto nesse nível. Fica mais na outra ponta, que é quem vai produzir servidores e tudo mais, seguir esse novo protocolo.
Vimos que HTTP2 é nada mais que o HTTP com algumas melhorias, até porque o HTTP1 estava bastante desatualizado em relação ao que o mercado já vinha sofrendo.
Também vimos que os headers são binários e eles são comprimidos com algoritmos chamados de HPACK.
Vimos ainda, que o HTTP2 habilita o GZIP como padrão na resposta, logo, esses dados vêm zipado. Coisa que tínhamos que configurar manualmente na versão anterior, ou seja, HTTP1.1.
Além disso, no HTTP2, as requisições e respostas podem ser paralelas. Não precisamos ficar esperando que uma requisição termine pra fazer a próxima. Temos uma otimização maior.
Outro assunto foi que os cabeçalhos guardam status. Quando enviamos uma requisição, a próxima, para o mesmo domínio, não precisa enviar os mesmo dados que já foram trafegados na última. Conclui-se que no HTTP2 isso é evitado, ou seja, menos informação enviada, menos dados que enviamos, menos banda que usamos do usuário, mais feliz ele fica.
Além de Headers Stateful, vimos também que o HTTP2 especifica o famoso Server-push, que é o ato do servidor enviar dados sem que o browser tenha pedido, que foi o que aconteceu lá no index.html. O HTTP2 pode enviar dados diretamente para o browser sem ficar esperando uma requisição. Assim, ele dá um passo além.
CURSO HTTP ATUALIZADO
MÓDULO 01: CONHECENDO O PROTOCOLO HTTP
No vídeo passado, conhecemos o projeto AluraBooks e os tópicos que abordaremos neste curso.
Você sabia que provavelmente já usou o protocolo HTTP várias vezes, apenas hoje? Se você acessou o site da Alura para assistir a este vídeo, você usou o HTTP. Não só o da Alura, mas todos os sites do mundo, usam este protocolo.
Mas como o HTTP funciona? E como podemos usá-lo para construir soluções web funcionais, escaláveis e seguras? Para falar disso, começaremos explorando o nosso projeto e procurando onde está o HTTP no Back-End e no Front-End do AluraBooks.
Abriremos o Terminal e abriremos a pasta do Back-End do projeto. Escreveremos o comando "npm run start-auth" e pressionaremos a tecla "Enter" para iniciar o projeto. O Terminal exibirá a seguinte mensagem:
json-server-api@1.0.0 start-auth
Node server.js
API disponível em http://localhost:8000
Perfeito! Isso significa que o comando funcionou. Em seguida, abriremos em outra aba a pasta do Front-End e vamos iniciá-lo usando o comando "npm start".
Pode ser que o projeto abra automaticamente no seu browser. Caso isso não aconteça, basta copiar o endereço em "Local" exibido no Terminal (http://localhost:3000) e colá-lo na barra de endereço do seu navegador.
Com o Front-End aberto, clicaremos com o botão direito em qualquer lugar da página e selecionaremos Inspecionar (ou "Inspect"). Isso abrirá um menu do lado direito da página. Na parte superior deste menu, procuraremos a aba "Rede" (ou "Network"). Se ela não estiver visível, clicaremos na seta para o lado direito, que exibirá as abas seguintes da lista.
Ao selecionar "Rede", encontraremos uma área em branco, onde serão exibidos diversos logs com informações e mensagens do HTTP. Para interagir com o Front-End, clicaremos no botão "Cadastrar-se" no topo da tela. Essa ação gerará um request HTTP.
Podemos preencher brevemente as informações de cadastro com informações fictícias, apenas para teste (nome, e-mail, endereço, CEP e senha). Ao clicarmos no botão "Cadastrar", obteremos uma mensagem indicando que o usuário foi cadastrado com sucesso e observaremos que o campo em branco na aba "Rede" será preenchido com algumas informações.
Clicaremos no segundo registro, de número 200, e perceberemos que surge uma série de informações do lado direito, na aba "Headers". Abordaremos essas informações em detalhe mais adiante, mas são elas:
· Request URL;
· Request Method;
· Status Code.
Abriremos a aba "Payload", ao lado de "Headers" e observaremos que isso nos dá acesso a um JSON que corresponde exatamente às informações preenchidas pela pessoa usuária na tela de cadastro. Com isso, observamos o HTTP sendo utilizado no Front-End.
Para identificarmos o HTTP trabalhando no Back-End, voltaremos ao Terminal, na aba usada para rodar o Back-End. Perceba que surgiu uma nova linha de log:
POST /public/registrar 200 5.621 ms - 207
Note que o número 200 aparece aqui novamente, além de outras informações, como o tempo total da requisição. O importante é o começo ("POST /public/registrar"). Esta é uma informação que veio do Front-End. O número 200 foi gerado pelo Back-End. Isso evidencia que o HTTP é sempre uma interação entre duas entidades, o cliente e o servidor.
Conhecendo o HTTP
"HTTP" é uma sigla que corresponde a Hypertext Transfer Protocol, ou seja, Protocolo de Transferência de Hipertexto. Ele é um protocolo de comunicação usado para transferir dados na web.
Podemos transferir quaisquer tipos de dados com HTTP: páginas HTML, scripts como o JavaScript, imagens e assim por diante.
A arquitetura HTTP é composta sempre por duas entidades: um cliente e um servidor. Mas isso já é conteúdo para o nosso próximo vídeo. Falaremos mais disso na sequência!
No vídeo anterior, entendemos onde encontramos o protocolo HTTP no Front-End e no Back-End do nosso projeto. Agora, vamos nos aprofundar em como essa comunicação entre as duas entidades funciona, a chamada Arquitetura HTTP.
O nosso projeto envolve três partes:
· Cliente (navegador);
· Servidor Front-End;
· Servidor Back-End.
O cliente é exibido no navegador enquanto os nossos dois servidores estão inicializados no Terminal. Até aqui, observamos alguns parâmetros do HTTP no browser, mas como será que essa comunicação acontece?
As camadas da internet
Para responder a essa pergunta, começaremos entendendo melhor quais são as camadas da internet e onde o HTTP se encaixa.
As duas primeiras camadas da internet são a Física e a de Enlace. Nelas, estão as partes físicas que possibilitam a nossa navegação via internet. Podemos citar como exemplos a conexão com cabos de fio, o Wi-fi e até o 5G.
A próxima é a camada de Rede. Um exemplo dessa camada é a conexão IP. Você já deve ter ouvido falar dos endereços IP, certo? Eles seencontram na camada de Rede.
Em seguida, temos a camada de Transporte, que engloba os protocolos TCP e UDP. Essa camada garante que as informações cheguem de um ponto A até um ponto B.
Por fim, temos a camada de Aplicação, onde está o HTTP. Essa camada é composta pelo browser usado no computador e no smartphone e pelos aplicativos instalados no celular. Toda vez que usarmos o HTTP, estamos usando a camada de Aplicação.
Assim, o HTTP é um protocolo da camada de aplicação.
Mas o que seria um protocolo?
Para responder a essa pergunta, usaremos uma analogia: um protocolo é como se fosse uma conversa. Se o nosso navegador pudesse enviar mensagens de WhatsApp para o servidor, a conversa entre eles seria semelhante à imagem abaixo:
O detalhe é que essa interação segue determinadas regras: se o cliente mandar uma mensagem e o servidor não responder, a coisa não funciona. Assim, um protocolo é uma conversa com regras.
E quais seriam as regras do HTTP?
Regras do protocolo HTTP
A primeira regra é que sempre deve haver duas entidades dialogando, sempre um cliente e um servidor.
Essa conversa é sempre iniciada pelo cliente. É o cliente quem pedirá o HTML, por exemplo, e não o contrário. O servidor não decidirá enviar informações ao cliente por conta própria.
Após a requisição do cliente, o servidor envia uma resposta com o que foi solicitado. O protocolo HTTP é baseado em mensagens de texto que seguem uma estrutura específica. Esse texto pode ser lido tanto por pessoas quanto por máquinas.
Por fim, temos uma camada sobre a qual o HTTP roda, ou seja, o Transmission Control Protocol - TCP. Essa é a camada de transporte, relevante para garantirmos que as mensagens HTTP chegarão ao seu destino com sucesso. Com isso, nenhuma das duas entidades ficará sem resposta.
Quais dispositivos podem usar HTTP?
Alguns dispositivos que utilizam o HTTP são:
· Servidores;
· Notebooks;
· Computadores desktop;
· Smartphones;
· Dispositivos inteligentes conectados à internet.
De modo geral, dispositivos que se conectam à internet possivelmente utilizarão o protocolo HTTP. Alguns dos exemplos menos comuns são geladeiras, lâmpadas conectadas, câmeras de segurança e assim por diante.
Voltando ao nosso projeto, estamos trabalhando com o navegador (cliente), um servidor Front-End e outro servidor Back-End. Como será que o HTTP se encaixa nessa conversa?
1. O navegador envia um request para o servidor;
2. O servidor responde conforme o que o navegador pediu;
3. O navegador envia uma mensagem para o Back-End;
4. O Back-End processa o requerimento;
5. Se o requerimento fizer sentido, o Back-End retornará uma resposta adequada.
Devemos nos lembrar que, embora o HTTP possa rodar em vários dispositivos diferentes, o projeto AluraBooks ainda está em um ambiente de desenvolvimento. Por isso, todas as entidades rodam diretamente em um único computador.
Neste vídeo, contextualizamos a Arquitetura do HTTP. Agora você já sabe o que é um cliente e um servidor. Ambos são entidades que se comunicam usando o HTTP e seguem determinadas regras para isso. No próximo vídeo, aprenderemos sobre endereços e URLs.
O HTTP foi criado para estabelecer regras de comunicação entre o modelo Cliente-Servidor que funciona na Web.
Para ilustrar: se você compreende este texto, é porque sabe português! Para que alguém consiga se comunicar com você, essa pessoa deverá usar o português também (supondo que você desconheça outro idioma). Isso significa que sua regra (protocolo) de comunicação com o mundo é a língua portuguesa, que define a forma com que as informações devem chegar até você (através do vocabulário, da gramática etc.). Uma outra pessoa que conheça português vai usar o mesmo formato, já que vocês têm um idioma em comum.
Na internet, como já vimos, o "idioma" mais comum é o HTTP. Ele é responsável por definir a forma de como os dados são trafegados na rede através de várias regras. Portanto, todo mundo que conhece o idioma HTTP poderá receber, enviar dados e participar dessa conversa!
Para saber mais: Peer-To-Peer
Você já usou torrent para baixar algum arquivo na internet? Caso sim, aproveitou um outro modelo de comunicação, o P2P ou Peer-To-Peer!
O modelo Cliente-Servidor não é o único modelo de comunicação na rede, nem sempre o mais adequado. Por exemplo, imagine que precisemos contar as letras de 20 palavras. No caso do modelo Cliente-Servidor, quem fará esse trabalho é o servidor, certo? E se precisar contar as letras de 1 milhão de palavras? Muito trabalhoso para o servidor, não?
O modelo Cliente-Servidor tenta centralizar o trabalho no servidor, mas isso também pode gerar gargalos. Se cada Cliente pudesse ajudar no trabalho, ou seja, assumir um pouco da responsabilidade do servidor, seria muito mais rápido. Essa é a ideia do P2P! Não há mais uma clara divisão entre Cliente-Servidor, cada cliente também é servidor e vice-versa!
Isto é útil quando você precisa distribuir um trabalho ou necessita baixar algo de vários lugares diferentes. Faz sentido?
Usando algum aplicativo de Torrent, o protocolo utilizado não é o HTTP, e sim o protocolo P2P, como BitTorrent ou Gnutella.
Para saber mais: arquitetura da Alura
PRÓXIMA ATIVIDADE
· 
· 
Agora já sabemos que existe um cliente, o navegador, como Chrome e Firefox, e um (ou mais) servidor HTTP. Para definir as regras de comunicação entre cliente e servidor, existe o protocolo HTTP.
Também já sabemos que o servidor usa alguma plataforma, por exemplo, no AluraBooks temos NodeJS no backend e React no frontend. Mas e aqui no site da Alura, qual plataforma realmente é utilizada? Não é tão fácil de descobrir, pois o HTTP, de propósito, não está focado em alguma plataforma específica e esconde isso de nós. Bom, eu não vou esconder nada e vou contar para vocês que a Alura usa a plataforma Java e o servidor concreto se chama Tomcat.
Também já falamos que o SQL é uma linguagem para consultar o banco de dados. Alura usa SQL para acessar o banco de dados MySQL. Com essas informações já temos uma breve ideia da arquitetura da Alura!
Cliente <--- HTTP ---> Servidor Java <--- SQL ---> Banco de dados
Analise o seguinte diagrama:
Há arquiteturas muito mais complexas, mas a grande maioria usa o protocolo HTTP no topo. O protocolo HTTP garante a conectividade. Isso quer dizer que o protocolo HTTP funciona em todos os lugares, sem ter problemas com firewalls e outras regras de segurança. Nós podemos nos conectar sem maiores problemas com qualquer servidor no mundo!
Nessa aula, você aprendeu a:
· Configurar o AluraBooks, o projeto que utilizaremos ao longo do curso;
· Contextualizar o HTTP nas camadas da Internet;
· Caracterizar o que é o HTTP, e quais os seus principais componentes;
· Identificar a arquitetura das comunicações utilizando HTTP.
MÓDULO 02: APRENDENDO SOBRE URLs
Olá! Estamos mais familiarizados com o projeto e como ele se estrutura em termos de arquitetura, como clientes e servidor, trocando mensagens HTTP, e seguindo as regras dos protocolos.
Agora vamos analisar um pouco as diferentes páginas que podemos acessar usando HTTP e comos nos referimos a cada página específica.
Acessando o navegador no endereço localhost:3000, estamos na aplicação AluraBooks. Aproveitando que já realizamos um cadastro, clicamos em "Login" no canto superior direito. Será exibida uma janela com o título "Login" e os campos "E-mail" e "Senha", abaixo temos um botão "Fazer login".
Dados que o instrutor preencheu para realizar o login:
· E-mail: geo@alura.com.br
· Senha: 123
Após clicarmos no botão "Fazer login", somos redirecionados para a página inicial, mas perceba que agora no canto superior direito ao invés de "Login" agora está escrito "Minha conta".
E se desejamos compartilhar a página do AluraBooks para um amigo? Ou até mesmo compartilhar a nossa página de perfil, clicando em "Minha conta". Precisamos nomear essas páginas, com um nome que qualquer pessoa entenda e consiga colocar no navegador, e buscar por elas. Mas como nomeamos as páginas?
Dar nome às páginas
Em 1991, o Tim Berners-Lee estava descobrindo o queusamos atualmente como web. E ele estava com essa mesma dúvida: como nomear páginas específicas?
Por exemplo:
· Página da maria
· https://twitter.com/maria
Vamos supor que uma amiga nossa chamada de Maria decidiu montar uma página. Ela pode colocar apenas "página da maria" ou precisará de mecanismos mais estruturados para nomear essa página e posteriormente se referir a ela para localizá-la?
URL (Uniform Resource Locator)
A resposta obviamente é que precisamos de um mecanismo padronizado, chamamos esse mecanismo de URL (Uniform Resource Locator, em português "Localizador de Recursos Universal").
O localizador nos permite acessar os recursos, que podem ser arquivos HTML, imagens, scripts de JavaScript que carregamos nas páginas, etc. É universal porque, como aprendemos, essas páginas podem ser carregadas em aplicações web, dispositivos móveis, servidor e desktop.
É na URL que nomeamos as páginas.
Vamos analisar o seguinte exemplo do nosso projeto
https://localhost:3000/
Compreenderemos as divisões da URL: o http delimita qual o protocolo utilizado para acessar a página. Nesse caso é o http, mas há outros, como o FTP (File Transfer Protocol) ou SSH (Secure Shell).
O //localhost:3000 é a parte que determina o servidor e qual a porta que a página web está disponível. No nosso caso é o localhost (computador do instrutor) na porta 3000.
Por fim, temos a barra / que representa o caminho (raiz), ou seja, onde está o recurso dentro de determinado servidor. Ao colocarmos a barra, geralmente é o primeiro recurso, a página principal do web site.
Composição da URL:
· http: Protocolo
· //localhost:3000: sendo "localhost" o servidor e 3000 a porta que a página web está disponível
· /: caminho (raiz)
Portanto, a partir da URL https://localhost:3000/ conseguimos carregar a página inicial que está no meu servidor localhost na porta 3000, usando o protocolo HTTP.
Vamos usar esse conhecimento sobre URLs para entender um pouco mais sobre como funciona os domínios, e como podemos estruturar e criar novas páginas no sistema web que estamos desenvolvendo.
Aprendemos como são formados os endereços das URLs, que usamos para acessar os recursos na web através do protocolo HTTP. Agora vamos focar em uma parte das URLs: as portas.
Acessando o navegador no endereço localhost:3000, estamos no nosso projeto AluraBooks. Já aprendemos que o número 3000 é a porta onde a página web está disponível. Mas vamos abrir uma nova aba e acessar o site da Alura .
Endereço do site da Alura: https://www.alura.com.br/
Compare as duas URLs. Observe que não temos o número da porta no endereço de site da plataforma da Alura. Isso acontece porque a maioria dos sites já utilizam uma porta padronizada, que já está especificada no padrão do HTTP, sendo a porta de número 80. Se adicionarmos o número 80 no endereço da Alura, funciona da mesma forma.
https://www.alura.com.br:80
Mas observe que após teclarmos "Enter", mesmo funcionando o navegador removeu a porta 80 do endereço, estamos somente com alura.com.br. Isso ocorre por ser a porta padrão mesmo, e não precisamos ficar exibindo no endereço.
Mas não temos somente a porta 80 como padrão:
Portas padrão
	Número da(s) porta(s)
	Padrão
	80
	HTTP
	443
	HTTPS
	de 1023 até 65535
	Livres para uso
portas entre 0 e 1023 são reservadas para serviços padronizados.
Nas portas livres para uso, estamos usando a 3000 no nosso front-end, e no back-end usamos a porta de número 8000. Usamos essas portão, então, para não influenciar as portas padrão, e para permitir a execução de mais de um servidor no mesmo computador simultaneamente.
Por fim, essas portas com número maior nos fazem perceber mais facilmente que estamos trabalhando no** ambiente de desenvolvimento**. Ou seja: o nosso projeto AluraBooks ainda não está pronto, estamos desenvolvendo na nossa máquina local.
Neste vídeo, aprendemos sobre as portas padrão e sobre como podemos configurar as portas. Na sequência, vamos entender mais sobre os domínios.
Já aprendemos bastante sobre URLs, e entendemos detalhes sobre as portas. Agora vamos compreender melhor a parte do servidor.
localhost:3000
Acessando a nossa aplicação pelo navegador no endereço localhost:3000, temos o nosso servidor como sendo o localhost (nome de domínio de onde estamos acessando o servidor) e a porta 3000.
Se acessarmos, por exemplo, o site google.com é outro nome de domínio, que conseguimos acessar de forma direta sem a necessidade de informar a porta (por ser padrão). Mas, e se colocássemos um endereço IP?
Endereço IP usado pelo instrutor:
http://142.251.128.14
Colando o endereço IP acima na barra de endereço do navegador e teclando "Enter", somos redirecionados para a página google.com.
O que será que aconteceu para um endereço IP virar o nome do site?
Sistema de Nomes de Domínios (DNS)
	Site
	IP
	google.com
	142.251.128.14
Todo computador precisa de um endereço IP para se conectar à internet. Entretanto, imagine se tivéssemos que ficar decorando endereços IPs de cada servidor conectado para acessarmos um site. O do Google, por exemplo, é o IP 142.251.128.14. Portanto, o DNS associa esse IP a um nome mais fácil de lembrarmos.
Os servidores DNS transformam requisições de nomes em endereços IP, isso para que a pessoa usuária consiga acessar a página web esperada quando digitar o nome de domínio no navegador web.
Domínios
O que são esses domínios?
Fazendo uma analogia, por exemplo, o Brasil é um domínio territorial por ser uma região administrativa que possui suas regras. Cada país é um domínio separado.
Na web, cada site, ou sistema, ou empresa possui seu próprio domínio, sendo onde tudo é controlado. Por exemplo, todos os sistemas da Alura estão sobre o domínio de alura.com.br; já o Google, está no domínio google.com e o nosso servidor local está em localhost. Este significa que o domínio funciona somente dentro do nosso computador.
Há domínios globais e domínios locais. Um exemplo de domínio global é o da Alura e do Google, já o domínio local é o nosso localhost.
Como funciona o DNS
Temos um servidor DNS que possui uma tabela grande, onde há uma coluna com o nome dos sites (domínios) e outra com os IPs relacionados aos domínios.
	Site
	IP
	google.com
	142.251.128.14
	alura.com.br
	172.67.72.232
	…
	…
Assim, toda vez que a pessoa acessar um site usando o HTTP, ela precisa saber qual o IP do servidor para que esse acesso seja efetivo. Dessa forma, perguntamos ao servidor DNS qual o IP, por exemplo, do domínio google.com e temos como retorno o 142.251.128.14. Com o endereço IP, a pessoa estabelece uma comunicação HTTP da forma como já aprendemos anteriormente.
Podemos fazer alguns testes relacionados a como descobrir o endereço IP.
No terminal, rodamos um programa através do comando nslookup google.com.
nslookup google.com 
Como retorno, obtemos:
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.251.128.14
Temos como retorno o nome do domínio e o endereço IP associado a ele. Podemos usar esse comando, portanto, para descobrir qual o endereço IP de determinado domínio.
Imagine o tamanho da tabela que esse servidor DNS precisa ter para saber todos os sites do mundo, e o tempo de busca e leitura do endereço IP que está associado ao domínio. Isso está relacionado à performance e também à administração.
DNS é hierárquico
Para simplificar, o DNS é feito de uma forma hierárquica em formato de árvore. Quando acessamos algo .com.br ou .org, significa que são o primeiro nível dos nomes dos sites. Inicia-se da raiz (nível mais abstrato) que é para ter um ponto de onde começar, e a partir disso vamos descendo os níveis. Chamamos esse nível de top-level domains (TLD) (em português, "domínios de nível superior").
Descendo para os sub-domínios, temos os domínios da alura, g1 e fiap, por exemplo, alura.com.br e do Google ficaria apenas google.com. Esse mecanismo hierárquico permite uma busca mais rápida por usarmos uma árvore.
Além disso, facilita na administração, por exemplo, por sabermos que tudo que contém br está relacionado ao Brasil. Assim, é possívelalocar essa parte dos domínios para ser administrada por uma entidade brasileira. Isso seria para cada país, assim eles conseguem gerenciar os seus domínios específicos.
Composição da URL:
· http: Protocolo
· //localhost: Endereço IP ou Nome de domínio.
· :3000/: caminho (raiz)
Portanto, na parte do servidor podemos usar tanto o endereço IP quanto o nome de domínio para acessar as páginas HTTP.
Nessa aula, você a aprendeu a:
· Identificar uma URL e entendeu o seu papel no protocolo HTTP;
· Configurar URLs para utilizar: protocolos, domínios, portas, e caminhos específicos;
· Utilizar a porta padrão nas URLs com o protocolo HTTP;
· Usar nomes de domínios (ao invés de endereços IP) para acessar diferentes sites na Web.
MÓDULO 03: INSPECIONANDO O PROTOCOLO HTTP
Recapitulando
Nós usamos o Chrome junto do JavaScript como um cliente HTTP, acessando nosso servidor do back-end e do front-end. Na aba de inspeção do navegador, mais especificamente na aba "Network" (Rede), analisamos informações obtidas de requisições.
Ao longo das aulas, descobrimos que o HTTP é um protocolo de textos. No entanto, apenas consultado os logs obtidos da requisição nessa aba, não temos certeza se são textos ou se o Chrome que está os organizando dessa forma.
Então, vamos introduzir uma nova ferramenta, chamada telnet, responsável por criar conexão TCP com outros servidores.
Telnet
Criaremos uma conexão TCP com back-end e o TCP será usado pelo HTTP para transportar as mensagens. Abriremos o telnet no terminal e digitaremos as mensagens HTTP como um cliente, semelhante ao navegador. A diferença é que o navegador realiza esse processo automaticamente, mas nós escreveremos as mensagens manualmente com telnet.
Em uma aba do terminal, temos o back-end rodando. Em outra aba, vamos usar o comando do telnet, passando como parâmetro o domínio e a porta:
telnet localhost 8000
Connected to localhost.
Em seguida, vamos fazer uma request, escrevendo o conteúdo da requisição HTTP.
GET / HTTP/1.1
O "GET" indica a obtenção de um conteúdo, a barra define que o conteúdo é da página inicial e o "HTTP/1.1" é o nome do protocolo, seguido da versão.
Pressionado "Enter" duas vezes, a resposta do servidor começa com HTTP/1.1 200 OK e uma série de configurações, que não precisamos nos atentar, por enquanto. Depois, temos todo o código HTML usado para renderizar a página inicial do AluraBooks.
Ou seja, fizemos uma requisição HTTP manualmente, usando o telnet! Na sequência, vamos realizar uma requisição um pouco mais interessante.
Na página inicial do AluraBooks, na parte superior direita, podemos clicar no botão "Login" e inserir nossos dados cadastrados no sistema:
E-mail: geo@alura.com.br Senha: 123
Pressionando o botão "Fazer login", entraremos no sistema, usando o protocolo HTTP. A seguir, vamos explorar como realizar a mesma ação com o telnet.
No terminal, podemos executar o comando clear para limpar a tela. Em seguida, abriremos uma nova sessão de telnet novamente:
telnet localhost 8000
E enviaremos a seguinte requisição:
POST /public/login HTTP/1.1
Content-Type: application/json
Content-length: 45
{"email": "geo@alura.com.br", "senha": "123"}
Dessa vez, informamos que estamos enviando um JSON e que o tamanho da requisição é de 45 bytes. Além disso, mandamos um JSON com dados de login.
Analisando o retorno, reparamos que a requisição foi bem-sucedida. A resposta em texto do servidor começa novamente com HTTP/1.1 200 OK e várias configurações. Depois, temos um JSON com um access token, que é o elemento usado para provar que estamos logados. Aprendemos sobre esse assunto mais adiante; por ora, vamos focar em entender o formato das mensagens HTTP.
Formato das mensagens HTTP
Aprendemos que a requisição tem o seguinte formato:
POST /public/login HTTP/1.1
Host: localhost
Content-Type: application/json
Content-length: 45
{"email": "geo@alura.com.br", "senha": "123"}
A linha inicial contém as informações principais sobre a requisição. O "POST" indica que estamos enviando conteúdo. Nas três linhas seguintes, temos os cabeçalhos (headers) com metadados sobre a requisição. Na última linha, consta o corpo da requisição (body). No caso, mandamos um JSON.
De maneira similar, a resposta também tem uma linha inicial, seguida de cabeçalhos e o corpo com a resposta:
HTTP/1.1 200 OK
X-Powered-By: Express
Vary: Origin, Accept-Encoding
(...)
Content-Type: application/json
Content-Length: 364
{
 "access_token: "eyJhiJ...WCbZof2rf",
 (...)
}
O objetivo deste vídeo era aprender que as mensagens HTTP tem esse formato específico de cabeçalhos e corpo.
Usamos o telnet, mas não precisamos usá-lo para sempre, afinal, ele é muito baixo nível. Nos próximos vídeos, aprenderemos a utilizar uma nova ferramenta: o Postman. Assim como o telnet, ele é poderoso e permite controlar os parâmetros HTTP. Assim como o Chrome, ele é mais amigável para utilizar.
Postman: saiba como instalar e dar seus primeiros passos
Introdução
Você já deve ter reparado que é comum que a pessoa desenvolvedora utilize serviços disponibilizados por aplicações de terceiros. Essas aplicações são conhecidas como APIs, sigla para Application Programming Interface, ou Interface de Programação de Aplicativos em tradução livre. Como exemplo de API temos a API do Google Maps, distribuída para incorporar funcionalidades de geolocalização em outras aplicações.
Vamos supor que você está trabalhando na construção de um blog de notícias e para isso é necessário trabalhar com dezenas de APIs em uma base diária, e que todas elas necessitam ser analisadas e testadas. Fazer isso manualmente levaria muito tempo e esforço e, por isso, surgiram ferramentas que facilitam o processo, como é o caso do Postman. Essa plataforma auxilia no processo de criação e também de utilização de APIs, automatizando vários processos e tarefas de forma eficiente e segura.
Utilizar o Postman nos trará vantagens como:
· Facilidade em criar, compartilhar, testar e documentar APIs.
· Converter JSON (JavaScript Object Notation) em várias linguagens.
· Automatizar e criar rotinas de testes.
· Sincronizar entre diversos aplicativos.
· Armazenar dados para uso em outros testes.
· Não precisa pagar para utilizar, entretanto, há recursos pagos.
Com o objetivo de facilitar sua rotina como pessoa desenvolvedora, neste artigo, aprenderemos a instalar e configurar o Postman nos ambientes Windows, Linux e Mac e faremos nosso primeiro teste com a ferramenta!
Postman: a história por trás da ferramenta de testes
Já no início deste artigo, percebemos que o Postman oferece muitas vantagens, não é mesmo? Mas você sabe como surgiu essa ferramenta tão poderosa?
Inicialmente o Postman surgiu como uma extensão para o navegador Google Chrome e tinha como objetivo simplificar o processo de testes de APIs. Porém, com o aumento do uso da ferramenta, a plataforma cresceu e precisou expandir para uma aplicação disponível em outros sistemas operacionais como o Windows, Linux e Mac.
Essa é uma ferramenta importante no trabalho da pessoa desenvolvedora, já que auxilia a construir, consumir, testar, documentar e compartilhar APIs. Além disso, o Postman permite que os usuários salvem e recuperem as respostas, de forma detalhada, das suas requisições HTTP e HTTPs. Isso ocorre através dos métodos de requisição ou verbos HTTP que indicam o que será feito com determinado recurso.
Você percebeu como o Postman é uma ferramenta valiosa? Grandes empresas também repararam isso!
O Twitter utiliza o Postman para auxiliar, integrar, educar e inspirar a sua equipe de desenvolvedores e aproveitar ao máximo as APIs em seu projeto. A Shopify usa para auxiliar a reproduzir e depurar bugs. O Imgur utiliza para apoiar a sua equipe a construir, testar, executar e gerenciar sua API, bem como entregá-la ao mercado.
Esses são apenas alguns exemplos de grandes empresas que usam essa ferramenta, não conseguiríamos citar todas já que atualmente o Postman possui mais de 17 milhões de usuários e 500 mil empresas utilizando seus serviços.
Agora que sabemos disso e entendemos a importância desse serviço,vamos aprender a instalar essa ferramenta?
Instalação no Windows
Vamos iniciar pela instalação do Postman no Windows?
Para começar devemos acessar a página de downloads no site oficial do Postman. O próprio site irá recomendar a versão mais adequada para sua máquina. Nesse artigo, foi indicada a versão “Windows 64-bit”, assim, clique em Windows 64-bit e será feito o download do executável do programa.
Logo após baixar, clique no arquivo e o programa será instalado automaticamente no seu computador.
Ao final da instalação, será feito um redirecionamento para uma página de Login do programa. Nesta página serão dadas as opções “Criar conta ou fazer login” (em inglês, “Create an account or sign in”) e logo abaixo da tela terá a opção de “Criar conta ou fazer login depois? Pule e vá para o aplicativo” (em inglês, ”Create your account or sign in later? Skip and go to the app”).
Clique na opção de pular e ir para o aplicativo e você será redirecionado para a página principal do Postman.
Obs: Estamos clicando na opção de pular o login e ir para o aplicativo, pois para estes primeiros passos com a ferramenta não é obrigatório realizar este procedimento. Contudo, com o decorrer da sua experiência com a aplicação, é recomendado possuir uma conta para usufruir de algumas funcionalidades.
Terminou de instalar? Vá no final desse artigo para aprender a dar seus primeiros passos nessa ferramenta!
Primeiros passos com o Postman
Agora que instalamos o Postman no sistema operacional, vamos dar nossos primeiros passos nessa ferramenta?
Aprendemos que o Postman facilita o dia-a-dia de uma pessoa desenvolvedora, visto que auxilia no teste e consumo de APIs através dos métodos de requisição HTTP. Os principais são: GET e POST.
· GET: É usado para buscar um recurso específico. Retorna apenas dados.
· POST: É usado para enviar dados a um determinado recurso.
Vale destacar que para utilizar o Postman é um pré-requisito conhecer HTTP, pois essa ferramenta aborda muitos conceitos relativos ao uso deste protocolo. Para isso, recomendamos, a fim de complementar os seus conhecimentos, a leitura do artigo HTTP: GET e POST - Conheça as diferenças entre os métodos na nossa plataforma.
Leu o artigo? Então vamos nessa!
Vamos supor que você é freelancer e recebeu um trabalho de uma empresa fictícia chamada “Correios Diretos” para verificar o endereço de alguns colaboradores através de uma famosa API que é a ViaCEP. Com essa API é possível verificar o endereço através de uma busca de CEP.
A URL disponibilizada por esta API para consultas de CEP está estruturada da seguinte maneira:
viacep.com.br/ws/01001000/json/
Onde deve ser informado um CEP no formato de 8 dígitos, como no exemplo: "01001000". Após o CEP, deve ser fornecido o tipo de retorno desejado, para este exemplo utilizamos o formato JSON.
Agora, vamos abrir o Postman.Após abrir o Postman, vamos selecionar a opção “new” (em português, “novo”) e após isso, selecionar a opção “HTTP Request” (em português, Requisição HTTP) destacada na imagem abaixo:
Feito isso, o Postman abrirá tela abaixo, que é onde vamos realizar as requisições.
Veja que a opção destacada abaixo lista diversas formas de realizar essa requisição. Como neste exemplo o objetivo é somente verificar e testar a API, iremos utilizar o verbo GET que nos devolverá o conteúdo solicitado através da URL que vimos anteriormente.
Sabendo que utilizaremos o método GET para recuperar as informações, agora precisamos informar qual CEP utilizar. Para este exemplo, utilizaremos este CEP: 04101300. Dessa forma a URL da API ficará da seguinte maneira:
https://viacep.com.br/ws/04101300/json/
Com essas informações, agora podemos selecionar o método GET e colar a URL na barra de busca. Após isso, clicamos no botão “send” (em português, “enviar”), conforme a animação abaixo:
No campo “Body” do Postman foram retornados os dados deste CEP, como: “logradouro”, “complemento”, “bairro” e entre outros. Além disso, o Postman nos informa outros dados importantes que estão destacado na imagem abaixo, como: Status: 200, que significa que obtivemos êxito na requisição; Time: 431ms, que mostra o tempo necessário para realizar esta requisição; Size: 749 B, que indica o tamanho em bytes dos dados desta resposta.
Neste primeiro exemplo obtivemos êxito com nossa busca, mas e se informarmos um CEP inválido?
Agora, vamos usar um CEP inválido com 7 dígitos para verificar o retorno. A URL ficará como abaixo:
https://viacep.com.br/ws/7777777/json/
Faremos o mesmo processo, mas o resultado obtido para esta requisição será:
No primeiro momento é possível notar que não recebemos uma resposta em JSON no campo “Body”, e sim um código em HTML, e o status para esta requisição foi 400, que significa que a resposta não foi encontrada devido algum problema com o endereço. Este resultado era esperado, tendo em vista que não preenchemos os 8 números que essa API esperava receber para procurar as informações do endereço.
Através desses dois exemplos apresentados anteriormente vimos como usar o Postman para testar a API ViaCEP. Para aprofundar um pouco mais seus conhecimentos em testes de APIs utilizando essa ferramenta, sugerimos o conteúdo Introdução ao Postman #AluraMais.
Conclusão
Nesse artigo aprendemos o que é o Postman, como instalá-lo nos mais famosos sistemas operacionais para computadores e fizemos também nosso primeiro teste com uma API! Mas não pare por aí, que tal potencializar sua aprendizagem acessando nossos materiais sobre esse conteúdo?
Para aprofundar seus conhecimentos introdutórios nesta aplicação, recomendamos o conteúdo de Introdução ao Postman #AluraMais. Além disso, veja sobre Testes de API com Postman.
Leia Também
· API do Google Maps
· HTTP: Desmistificando o protocolo da Web
· HTTP: GET e POST - Conheça as diferenças entre os métodos
Depurando métodos HTTP
Anteriormente, usamos o telnet no terminal, escrevemos mensagens manualmente e aprendemos sobre o formato das mensagens HTTP. Tanto na requisição quanto na resposta, temos os cabeçalhos seguidos do corpo da mensagem.
Agora, vamos continuar nos aprofundando no formato dos cabeçalhos de requisições, mais especificamente na linha inicial, por exemplo:
POST /public/login HTTP/1.1
A primeira palavra da linha tem um nome técnico: o método do HTTP. Para continuar explorando esses conceitos, vamos aprender a usar o Postman, uma ferramenta mais intuitiva que o telnet e bastante poderosa para manipulação de parâmetros.
Postman
O Postman é uma ferramenta para testar servidores HTTPs, APIs e assim por diante. Ao abrir o Postman, há um menu lateral à esquerda e uma área de trabalho (chamada de workbench) à direita.
Na parte superior do workbench, clicaremos no ícone de mais (+) para criar uma aba com uma nova requisição. No topo dessa aba, temos três elementos:
1. À esquerda, há um menu dropdown em que é possível alternar entre diversos métodos do HTTP — por padrão, o método GET está selecionado.
2. No centro, há um campo para digitar a URL.
3. À direita, temos um botão azul escrito "Send" (enviar).
Começaremos enviando uma requisição para obter as informações da página inicial do AluraBooks. Logo, selecionaremos o método GET e digitaremos a seguinte URL:
http://localhost:3000/
A barra ao final da URL indica que se trata da página inicial (home). Ao pressionar o botão "Send", recebemos a resposta na parte inferior da interface. No caso, trata-se do código HTML contendo todas as informações necessárias para desenhar a nossa tela do front-end. Nossa requisição foi bem-sucedida!
A seguir, vamos usar um método diferente: o POST. Podemos simplesmente reproduzir a requisição que fizemos no vídeo anterior, em que realizamos o login.
Dessa vez, selecionaremos o método POST. A URL também será diferente, dado que o destino agora é o back-end:
http://localhost:8000/public/login
Não precisamos escrever manualmente as informações do cabeçalho (como HTTP/1.1), pois o Postman ficará responsável por essa parte. Porém, é necessário definir o conteúdo da mensagem — o corpo da requisição. No caso, trata-sede um JSON com o e-mail e a senha para login.
Abaixo do campo em que digitamos a URL, há um menu com várias abas. Acessaremos a aba "Body", depois selecionaremos as opções "raw" e "JSON". No campo de texto exibido abaixo, informaremos o corpo da mensagem:
{"email": "geo@alura.com.br", "senha": "123"}
Por fim, clicaremos no botão "Send" para enviar a requisição. Na parte inferior, recebemos a resposta com o token de acesso, que podemos usar para acessar páginas protegidas.
Métodos HTTP
Ao clicar na seta do menu dropdown, temos uma lista de métodos HTTP. Sabemos que o GET serve para obter informações. Já o POST tem o significado de criar elementos. No caso, estamos enviando nossas credenciais e criando um token de acesso que pode ser usado para login.
Há uma lista extensa de métodos, mas os usados com mais frequência são apenas quatro:
	Método
	Significado
	POST
	criar (create)
	GET
	ler (read)
	PUT
	atualizar (update)
	DELETE
	apagar (delete)
Como estudamos, o POST serve para criar elementos (create) e o GET é utilizado para ler ou obter informações (read). O PUT é o método HTTP usado para atualizações (update), por exemplo, atualizar o endereço ou a senha. Já o DELETE é responsável por apagar elementos (delete), por exemplo, uma conta ou fotos salvas.
Esses métodos HTTP são tão comuns que foi criado um acrônimo, conforme seus significados em inglês, o CRUD:
· C: create
· R: read
· U: update
· D: delete
Esses métodos permitem que façamos a maioria das operações necessárias para nossas aplicações, por exemplo, o AluraBooks. No próximo vídeo, continuaremos explorando o HTTP e entenderemos o que podemos fazer com o token que recebemos do login.
Configurando cabeçalhos para autenticar usuários
prendemos a usar o Postman e entendemos os significados dos métodos HTTP. Além disso, fizemos o login por meio do Postman e obtivemos um código de acesso. Ele permitirá o acesso a informações restritas a um usuário específico.
Com o AluraBooks aberto no navegador, vamos clicar no botão "Login" na parte superior direita e entrar no sistema:
· E-mail: geovane@alura.com.br
· Senha: 123
Após entrar, acessaremos o link "Minha conta" na parte superior direita da tela, onde antes tínhamos o botão para login. Nessa página, temos nossa lista com detalhes de pedidos.
Essa página é protegida, apenas a minha conta tem acesso a essa lista. Não faria sentido se, ao entrar em minha própria conta, eu pudesse consultar os pedidos de outra pessoa (nem que outra pessoa pudesse conferir a minha lista).
Acessando uma página protegida
Nós já fizemos o login por meio do Postman e recebemos um token de acesso. A seguir, vamos explorar como entrar na página de pedidos, acessível apenas para usuários logados.
Como a meta é ler os pedidos, usaremos o método GET e nossa URL será a seguinte:
http://localhost:3000/pedidos
Ao enviar a requisição, recebemos o seguinte retorno na parte inferior do Postman:
{
 "status": 401,
 "message":"Token inválido"
}
Recebemos um resultado inesperado! Em vez de ler os pedidos, obtemos uma mensagem de token inválido. Nós já tínhamos obtido o token, então por que não conseguimos acessar?
Os servidores HTTP são stateless. Em outras palavras, os servidores HTTP não guardam estados, portanto não se lembram do aconteceu em requisições anteriores. No caso, ele não lembra que já havia nos autenticado no sistema.
A implicação é que precisamos continuamente comprovar ao servidor quem somos e que já fomos autenticados. É como mostrar nossa identidade e dizer:
"Servidor, sou eu de novo, o Geovane. Eu que estou tentando te acessar. Lembra que você já me autenticou? Aqui está a minha prova"
Logo, precisamos encontrar um jeito de enviar nosso token para o servidor em todas as requisições!
De início, vamos criar outro token de acesso, realizando o login novamente. No Postman, basta enviar uma requisição GET para a página de login, lembrando de informar as credenciais no corpo da requisição:
http://localhost:3000/login
{"email": "geovane@alura.com.br", "senha": 123}
Após enviar, copiaremos o token de acesso obtido na resposta do servidor. A seguir, começaremos a configurar os cabeçalhos da requisição!
Configurando cabeçalhos
No Postman, no menu abaixo da URL, acessaremos a aba "Headers". Nessa aba, há uma tabela cujas primeiras colunas são "Key" (chave) e "Value" (valor). Os cabeçalhos sempre seguem essa estrutura de chave e valor, como o Content-length: 45, que verificamos em aulas passadas.
Na primeira linha da tabela, vamos inserir a chave "Authorization", pois queremos que o servidor entenda que estamos autorizados a acessá-lo.
No valor correspondente, não basta colar o token, é preciso adotar a convenção do uso da palavra "Bearer". Em inglês, bearer significa portador, é a pessoa que carrega algo. Ou seja, é como se estivéssemos carregando nosso documento de identidade.
Portanto, vamos escrever "Bearer", colocar um espaço e colar o token:
	Key
	Value
	Authorization
	Bearer eyJhbGci0iJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Imd1b0BhbHVyYS5jb20uYnIiLCJzZW5oYSI6IjEyMyIsIm1hdCI6MTY30DQ3MTU20Cwi ZXhwIjoxNjc4NTEONzY4fQ.ZV5Z97oY7H94_hRDCX66Yf03G-wAQ8jNN-ARvhqKP6E
Lembre-se de usar o seu próprio token!
Agora que configuramos nosso cabeçalho para lembrar o servidor quem somos, vamos tentar acessar a página protegida novamente. Faremos uma requisição GET para a página de pedidos:
http://localhost:3000/pedidos
Ao enviar a requisição, a resposta do servidor serão os dados dos nossos pedidos! A estrutura é parecida com a seguinte:
[
 {
 "id": 89019041,
 "data": "2022-05-26",
 "entrega": "2022-05-26",
 "total": 29.9
 },
 {
 "id": 89019963,
 "data": "2022-07-26",
 "entrega": "2022-08-01",
 "total": 58.8
 }
]
Apesar de ser em formato JSON, trata-se das mesmas informações que conferimos no front-end.
Formas de "lembrar" o servidor
Aprendemos que, por padrão, o servidor é stateless, logo ele não se lembra do que aconteceu em requisições anteriores. No entanto, existem algumas formas de o lembrarmos.
Uma das formas é o uso da sessão, que foi a abordagem que empregamos. Por exemplo, gerar um token e mostrá-lo ao servidor continuamente para ele lembrar quem está o acessando. A sessão é o tempo que a pessoa usuária permanece logada no sistema.
Outra forma é o uso de cookies. É comum a exibição de um pop-up na tela para a pessoa usuária aceitar ou rejeitar o uso de cookies em sites. Eles são um mecanismo utilizado nos cabeçalhos do HTTP para que o servidor peça para a pessoa cliente salvar algumas informações, que serão usadas posteriormente para lembrar o servidor.
Neste curso, não entraremos em detalhes sobre os cookies, mas deixaremos um "Para saber mais" com uma explicação excelente sobre o funcionamento deles.
Na sequência, continuaremos aprendendo mais sobre as respostas HTTP.
Depurando os códigos resposta HTTP
Em aulas anteriores, analisamos algumas informações no painel de inspeção do Chrome. Na página inicial do AluraBooks, clicamos com o botão direito do mouse no centro da tela e selecionamos "Inspecionar".
No menu superior do painel de inspeção, acessamos a aba "Network" (rede), onde aparecem diversos logs referentes às requisições do HTTP. Na ocasião, conferimos os logs do acesso à página "Minha conta", que faz uma requisição para o caminho "pedidos". Verificamos a seguinte informação:
Status Code: 200 OK
Ao lado dessa informação, há um círculo verde e concluímos que parecia um bom sinal.
No Postman, há uma barra acima da área onde recebemos a resposta do servidor. Na parte direita, é possível verificar o status code.
Além do "200 OK", já encontramos outros códigos de status ao longo deste curso. Ao enviar uma requisição para /pedidos sem informar o token, por exemplo, obtivemos o status "401 Unauthorized", isto é, "Não autorizado".
A seguir, vamos aprender o que são esses códigos e sua importância.
Códigos de status
Por ser um protocolo, o HTTP segue algumas regras. Então, vamos consultar o documento RFC 7231, que define as regras do protocolo HTTP.RFCs são documentos que definem as regras de um protocolo. Elas são gratuitas na internet e qualquer pessoa pode acessá-las.
Descendo a página, encontraremos o sumário com todas as definições do HTTP. Por exemplo, na seção 4.3, temos subseções para os métodos que estudamos anteriormente — GET, POST, PUT e DELETE. Você pode ler por conta própria, caso te interesse.
Na seção 6, temos os códigos de status das respostas. Nas subseções, podemos identificar alguns que já conhecemos, como o "200 OK". O status "401 Unauthorized" não consta no sumário, mas ele aparecerá ao longo do documento.
Portanto, nessa seção, temos uma lista dos principais códigos de respostas do HTTP. Perceba que eles estão organizados em classes, de modo que já temos noções do seu significado ao examinar o primeiro dígito.
Os códigos que começam com o número 1 são raramente usados. Mais adiante, estudaremos a troca de protocolos (de HTTP para HTTPS, por exemplo) e encontraremos o status "101 Switching Protocols".
Os códigos iniciados com o número 2 indicam operações bem-sucedidas, como quando conseguimos criar um token ou acessar o conteúdo de um recurso HTTP. É o caso do "200 OK", com o qual já estamos familiarizados.
Os códigos que começam com o número 3 indicam redirecionamentos. Por exemplo, caso uma empresa mude de nome e o domínio de seu site seja alterado, ela pode usar um redirecionamento. Assim, quando uma pessoa acessar o domínio antigo, o HTTP a enviará para o novo site.
Como comentamos anteriormente, o HTTP tem duas entidades conversando: o cliente e o servidor. Os códigos que começam com o número 4 indicam erros provindos do lado do cliente, como "400 Bad Request" e "401 Unauthorized".
Já os códigos iniciados com o número 5 indicam erros do lado do servidor. Você provavelmente já se deparou com o código "500 Internal Server Error" (erro interno do servidor), quando algum site estava com problemas. No caso de erros, os servidores são configurados para responder com códigos iniciados com 5.
Esses códigos já definidos nos ajudam a criar aplicações fáceis de integrar. Vamos supor que trabalhamos em time de tecnologia. Nós somos responsáveis pelo back-end e há outras pessoas encarregadas do front-end. Ao usar esses métodos conforme as definições da RFC, a comunicação torna-se mais simples entre todos, já que se trata de uma linguagem universal.
Sendo assim, aprendemos sobre o formato das mensagens HTTP, detalhes sobre requisições e respostas, e como realizar o login com o token.
Falando em login, será que ele está protegido? Será que o sistema AluraBooks está seguro? Vamos explorar esse assunto na próxima aula.
MÓDULO 04: Protegendo a Web com HTTPS
 Até aqui, já exercitamos bastante como fazer login e requests usando o Postman. É importante que a nossa aplicação esteja segura, especialmente ao fazermos o login. Seria muito ruim se alguém descobrisse o nosso login e senha.
Para simularmos uma situação em que um hacker entra na nossa rede e intercepta os requests HTTP, usaremos um programa chamado Wireshark. O Wireshark observará tudo o que passa pela rede do nosso computador. Assim, simularemos um ataque hacker.
Abriremos o Wireshark e selecionaremos a interface Loopback. Esta é a interface que roda apenas no meu computador. Iniciarei a captura clicando no primeiro botão no menu superior.
Ao iniciá-la, diversos logs aparecerão. Por isso, é melhor usarmos um filtro para selecionarmos apenas a porta TCP número 8000. Para isso, digitaremos "tcp.port == 8000 && http" no campo de texto exibido no topo da interface e pressionaremos a tecla "Enter" em seguida. Agora, os requests só aparecerão quando feitos no Postman.
Ao abrir o Postman, veremos um request montado (o mesmo usado para fazer login), pertencente ao método "Post": http://localhost:8000/public/login. O corpo da mensagem é composto pelo e-mail e pela senha. Ao clicarmos no botão "Send", receberemos a resposta "200 OK" logo abaixo da primeira caixa de texto do Postman. Logo abaixo, será exibido o token de acesso.
Voltando ao Wireshark, descobriremos se ele conseguiu capturar o request. Observaremos duas linhas na parte de cima da janela: uma delas é o request (POST /public/login)
Podemos observar os detalhes na metade inferior da tela, especialmente na aba à direita. Descendo até o fim do texto, encontraremos um JSON com o nosso e-mail e senha.
Com isso, percebemos que o Wireshark conseguiu capturar o protocolo de texto e ler o seu conteúdo. Desse modo, temos uma falha de segurança no projeto. Para resolvê-la, introduziremos a versão segura do HTTP: o HTTPS.
Para realizar essa modificação, o primeiro passo é gerar uma entidade e uma chave de criptografia para o nosso site. Faremos isso digitando o seguinte comando no Terminal, na pasta "api-alurabooks", e pressionando a tecla "Enter" em seguida:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt
Usaremos o OpenSSL, um programa que trabalha com criptografia. Ele será usado para gerar tanto a chave privada do servidor quanto o certificado do servidor, ou seja, a sua identidade.
Depois disso, o Terminal pedirá algumas informações, como o nome do país (Country Name), o estado (State or Province Name), a cidade (Locality Name), o nome da organização (Organization Name), o departamento (Organizational Unit Name), um nome comum (Common Name) e o endereço de e-mail (Email Address).
Pularei algumas informações, preenchendo apenas o nome do país ("BR") e o nome da organização ("AluraBooks"). Usaremos o comando "ls" para observar que foram criados os arquivos "server.key" e "server.crt".
Com isso, já temos as informações necessárias para proteger os dados. Precisamos implementar então o código responsável por essa proteção. Para isso, acessaremos o VS Code, onde já está aberta a pasta "api-alurabooks", e abriremos o arquivo "server.js".
Nele, importaremos o módulo de HTTP digitando const https = require('https') no topo do código, logo abaixo dos outros const do arquivo.
Agora, precisamos envelopar o conteúdo do servidor nesse novo módulo HTTPS. Assim, desceremos até o fim do código, antes de o servidor começar o processo de listening na porta 8000. Pressionaremos a tecla "Enter" logo abaixo da linha server.use(router) para abrir espaço.
Digitaremos https.createServer({}). Dentro das chaves ({}), inseriremos os parâmetros para passar os arquivos que acabamos de criar no terminal. O primeiro é a chave privada (server.key) que precisa ser lida, o segundo, o certificado (server.crt). O resultado é o seguinte:
https.createServer(
 {
 key: fs.readFileSync('server.key'),
 cert: fs.readFileSync('server.crt')
 },
)
Em seguida, passaremos a variável server usada para fazer o listen como um parâmetro para o módulo de HTTPS. Por fim, mudamos o último trecho de código, retirando o server do trecho que faz o listen. Em vez disso, quem fará esse processo é o próprio https.createServer().
Podemos também modificar a mensagem do console.log para indicar que a API agora estará disponível em https:
https.createServer(
 {
 key: fs.readFileSync('server.key'),
 cert: fs.readFileSync('server.crt')
 },
 server
).listen(8000, () => {
 console.log("API disponível em https://localhost:8000")
})
Salvaremos as alterações e voltaremos ao Terminal, na aba de execução da API e pressionaremos o atalho "Ctrl + C" para pausar a execução. Em seguida, executaremos novamente usando o comando "npm run start-auth". A mensagem exibida no Terminal será:
API disponível em https://localhost:8000
Agora, abriremos o Postman e, se tentarmos fazer um request, obteremos um erro. Isso acontece porque ainda não mudamos de "http" para "https". Corrigiremos esse problema atualizando o endereço para "https://localhost:8000/public/login". Clicaremos em "Send" e obteremos um token de acesso que utiliza o HTTPS.
Em seguida, verificaremos se o Wireshark conseguiu capturar as informações transmitidas via HTTPS. Com o filtro usado, estamos vendo apenas as atividades com HTTP. O Wireshark não nospermite filtrar por HTTPS porque ele usa um protocolo chamado TLS, que corresponde à segurança da camada de transporte sobre o TCP.
Por esse motivo, atualizaremos a barra de texto no topo do Wireshark para "tcp.port == 8000 && tls". Ao fazer isso, ele exibirá as mensagens enviadas de maneira criptografada, com o HTTPS que habilitamos.
As mensagens enviadas são as que contêm o texto "Application Data" na coluna "Info". Ao selecionar uma delas, observe que já não é mais possível compreender boa parte do seu conteúdo. No canto inferior direito, perceberemos que os dados estão criptografados.
Neste vídeo, habilitamos o HTTPS com sucesso e demonstrar que ele deixa as nossas páginas mais seguras. Até mais!
Acabamos de aprender a proteger as nossas mensagens utilizando o protocolo HTTPS. Agora, garantimos que o nosso usuário e a nossa senha não serão interceptados na rede.
Relembrando que usamos o módulo https do Node.js para criar um servidor seguro. Seus parâmetros são uma chave privada (server.key) e um certificado (server.crt).
Para compreender que arquivos são esses, abriremos o Terminal na pasta "api-alurabooks". Se digitarmos "ls" e pressionarmos a tecla "Enter", poderemos identificar o certificado e a chave, "server.crt" e "server.key" respectivamente:
README.md package-lock.json server.js usuarios.json
database.json package.json server.key
node_modules server.crt thumbnail.png
Podemos inspecionar o conteúdo destes arquivos usando o comando "cat". Este comando imprimirá na tela o conteúdo de cada arquivo inspecionado. Para inspecionar o certificado, escreveremos no Terminal "cat server.crt".
No caso do certificado, surge uma sequência de letras e números ininteligíveis. Existe outro comando baseado no programa OpenSSL capaz de decodificar o conteúdo do certificado. Assim, digitaremos "openssl x509 -in server.crt -text" no Terminal e pressionaremos a tecla "Enter".
O resultado exibe a versão do certificado, seu número serial e outras informações, como o país ("BR") e a organização que criamos para o certificado ("AluraBooks"). Também aparece a chave pública ("Public-Key") e a assinatura gerada para o certificado ("Signature Algorithm").
Para inspecionar a chave, usaremos o comando "openssl rsa -in server.key -text -noout" e pressionaremos a tecla "Enter". A mensagem exibida nos mostra que se trata de uma chave privada ("Private-Key") de 2048 bits que usa o RSA. Esta sigla diz respeito ao algoritmo de criptografia que pode ser utilizado com essa chave. Na sequência, poderemos observar alguns parâmetros específicos e diversas sequências de números e letras.
Para compreender melhor como o certificado e a chave privada são utilizados, usaremos uma analogia. Imagine que você trabalha na modalidade presencial e precisa acessar o prédio onde fica a sede da empresa.
Para fazer isso, você apresenta o seu documento de identidade para uma autoridade que verifica quem pode entrar. Uma vez dentro do prédio, você usa uma chave para abrir a porta do escritório de trabalho.
É importante dizer que você jamais faria uma cópia da chave do seu escritório para entregar a um amigo ou amiga, por exemplo. Essa pessoa não tem autorização para entrar no seu escritório, pois ela poderia encontrar informações sensíveis lá que não lhe dizem respeito.
A chave e o certificado usados no nosso projeto funcionam de maneira similar: no lugar do documento de identidade, usamos um Certificado Digital. Trata-se de um documento com informações da sua API, sendo elas a identidade da organização, a chave pública e a assinatura digital.
O servidor mostra o Certificado Digital para o cliente em um processo de autenticação. Além disso, também contamos com uma chave privada que o servidor usa para proteger os dados. Esta chave nunca deixa o servidor, assim como não fazemos uma cópia da chave física do escritório.
Se essa chave deixasse o servidor, outros clientes poderiam descriptografá-la e descobrir os dados de outras pessoas.
Para recapitular, até aqui aprendemos como funciona a arquitetura do HTTP, formada por um cliente e um servidor que trocam mensagens entre si em formato de texto.
Estas mensagens estão protegidas com HTTPS, graças a uma chave privada que fica no servidor Back-End e a um certificado enviado para o cliente. O cliente também possui uma chave privada para criptografar os dados. No entanto, essa chave privada do cliente não tem um nome específico, pois uma chave nova é gerada para cada conexão utilizada.
Uma vez que servidor e cliente trocam as informações necessárias, eles conseguem criptografar os dados. O cliente envia os dados que, antes de serem transmitidos pela rede, passam por um algoritmo de criptografia. O servidor recebe e descriptografa esses dados. Na hora de enviar uma resposta, esta também é criptografada e recebida pelo cliente.
Acabamos de abordar como proteger os nossos dados com HTTPS e falamos do papel das chaves privadas e dos certificados digitais. Espero que você esteja gostando do curso. Na próxima aula, aprenderemos a usar os parâmetros no HTTP e a configurar o formato dos dados enviados no corpo da mensagem. Até mais!
MÓDULO 06: Controlando o HTTP
Retomando o projeto do AluraBooks, vamos seguir explorando as capacidades do protocolo HTTP. Aprenderemos como filtrar livros por categorias e também como criar novos livros.
Acessando pelo navegador o endereço localhost:3000e descendo a página da aplicação até a seção de "categorias mais buscadas", temos as seguintes categorias:
· Android;
· orientação a objetos;
· marketing digital;
· agile;
· startups;
· HTML e CSS;
· Java;
· Python.
Vamos entender como podemos manipular o nosso back-end para fazer esse filtro. Isso para que quando implementarmos essa parte no front-end já vamos saber como filtrar através do HTTP.
No Postman, estamos com o método get e o endereço http://localhost:8000/ (URL do back-end). No final da URL colocamos /livros.
http://localhost:8000/livros
Em seguida, clicamos no botão "Send", para enviar a requisição.
Como retorno, temos um JSON no corpo da resposta. Nele, temos vários livros com os campos id, categoria, título, slug, descrição, isbn, número de páginas, etc.
Retorno do JSON (não exibimos todos os campos)
[
 {
 "id": 1,
 "categoria": 3,
 "titulo": "Acessibilidade na Web",
 "slug": "acessibilidade-na-web",
 // retorno JSON omitido
 }
]
Mas o que são esses números da categoria? O que estamos visualizando é o id. Para acessarmos essas categorias, vamos até a URL e no final ao invés de /livros colocamos /categorias.
http://localhost:8000/categorias
Depois clicamos no botão "Send".
Como retorno, temos:
[
 {
 "id": 1,
 "nome": "Programação",
 "slug": "programação"
 },
 {
 "id": 2,
 "nome": "Mobile",
 "slug": "mobile"
 },
 {
 "id": 3,
 "nome": "Front-end",
 "slug": "frontend"
 },
 {
 "id": 4,
 "nome": "Infraestrutura",
 "slug": "infraestrutura"
 },
// retorno omitido
]
Note que cada id está associado a uma categoria. Vamos filtrar os livros da categoria de front-end, que é o de número 3. No final da URL colocamos /livros no final e clicamos em "Send".
http://localhost:8000/livros
Perceba que nesse retorno temos livros de todas as categorias, para filtrarmos os da categoria de front-end precisamos passar parâmetros para o servidor para instruirmos ele a realizar o filtro. Para passarmos esses parâmetros pela URL, após o /livros usamos o sinal de interrogação passando categoria=3, por exemplo. Ou seja, o nome da variável que desejamos filtrar e o valor.
Assim, ficamos com:
http://localhost:8000/livros?categoria=3
Ao clicarmos em "Send", temos no corpo da resposta somente livros da categoria 3 referente ao front-end.
É assim que passamos os parâmetros usando o método get.
O método get é usado para ler dados.
Ao invés de filtrarmos a categoria de um livro, vamos cadastrar um novo livro. Para isso, precisamosmontar um JSON parecido com o que temos no retorno.
JSON já montado pelo instrutor:
{
 "id": 34,
 "categoria": 3,
 "titulo": "Novo livro",
 "slug": "novo-livro",
 "descricao": "Livro do curso HTTP",
 "isbn": "978-65-1111-11-1",
 "numeroPaginas": 200,
 "publicacao": "2023-01-01",
 "imagemCapa": "heetps://raw.githubusercontent.com/viniciosneves/alurabooks/cursp-novo/public/imagens/livros/acessibilidade.png",
 "autor": 1,
 "opcoesCompra": [{
 "id": 1,
 "titulo": "E-book",
 "preco": 29.9,
 "formatos": [".pdf", ".pub", ".mob"]
 }],
 "sobre": "Compre esse livro e aprenda tudo sobre HTTP."
}
Já que usamos para filtrar os parâmetros daquela forma com o get, com o post passamos o JSON completo após o sinal de interrogação? Acho que não, né. Quando usamos o método post, é comum enviarmos informações maiores e, por isso, ao invés de usarmos a URL com o parâmetro de busca, utilizamos o corpo da mensagem do post para enviar esses parâmetros para o servidor.
Mudamos o verbo de get para post antes do endereço, depois selecionamos a aba "body" abaixo da URL que estamos em /livros, e no mesmo nível da aba na caixa de escolher colocamos a opção "raw" (mensagem escrita de forma crua) e em "text" colocamos JSON. Na sequência, colamos o JSON no corpo no campo em branco.
Lembrando que estamos usando o endereço http://localhost:8000/livros
Para criarmos o livro, vamos enviar a nossa requisição clicando no botão "Send". No retorno, temos informando o Status 201 Created, significa que foi criado.
Para testar, colocamos o método get novamente, apagamos o conteúdo no formato JSON que colamos (o get não usa o corpo da mensagem) e depois clicamos em "Send". Usamos o mesmo endereço http://localhost:8000/livros.
Descendo até o último livro do retorno, temos o nosso "Novo livro" criado com sucesso. Observe que é o id de número 34, com a categoria 3 e o título "Novo livro". Agora esse livro faz parte da nossa coleção de livros do back-end.
Enviando parâmetros
Usamos dois métodos ao longo desse vídeo:
· get (leitura);
· post (criar).
No get usamos o que chamamos de query params (em português, "parâmetros de consulta"), como, por exemplo, o /livros?categoria=1 (passamos direto na URL). No post, enviamos os parâmetros pelo corpo da mensagem, porque são dados maiores, usando o formato JSON, XML, etc.
No próximo vídeo, aprenderemos como determinar o formato dessas mensagens que serão enviadas no corpo da mensagem.
Recapitulando: o formato das mensagens HTTP possuem um header e um corpo. Temos uma requisição preparada (get) para o back-end no recurso /livros. Clicando em "Send", temos como retorno um JSON com todos os livros disponíveis no back-end do AluraBooks.
Mas como sabemos que é um JSON? Podemos confirmar qual a estrutura analisando os cabeçalhos do HTTP. Para isso, clicamos na seta apontando para baixo "∨" ao lado do "Body", vamos ter quatro opções:
· Body;
· cookies;
· headers;
· test results.
Selecionamos "headers", e temos os cabeçalhos das respostas. Um desses cabeçalhos é chamado de Content-Type (em português, "tipo do conteúdo"), e analisando o valor dele temos application/json;charset=utf-8. Isso nos informa que é um JSON. A parte charset=utf-8 é para informar que esse JSON irá suportar caracteres com acentos, mas o importante é a parte que informa application/json.
Voltando para o body, vamos supor o seguinte cenário: estamos trabalhando na empresa que está construindo o AluraBooks e fazemos parte do time de back-end. Precisamos compartilhar a API com a equipe do front-end, que vão precisar saber como acessar o recurso /livros ou qualquer outro recurso e como usar parâmetros para filtrar, etc.
Como compartilhamos esse conhecimento? Com uma página hospedada na nossa própria API. Vamos concordar que não faz sentido ser uma página em formato JSON porque ele é feito para a máquina ler.
Primeiro, precisamos criar uma nova rota, uma possibilidade de acessarmos a parte com a documentação. Posteriormente, desejamos que quando uma pessoa acessar esse novo caminho da URL, que esse código seja renderizado como um HTML para que humanos consigam ler. Faremos justamente isso.
No VS Code, no final do arquivo server.js para adicionarmos uma nova rota para a URL do HTTP. Deixamos um trecho pronto para você só copiar e colar com esse novo caminho.
Trecho de código com o caminho usado pelo instrutor
server.get('/public/docs', (req, res) => {
 const meuHtml = `
 <h1>Documentação da API</h1>
 <ul>
 <li>GET /livros</li>
 <li>POST /livros</li>
 <li>GET /categorias</li>
 </ul>
 `
 res.status(200).contentType("text/plain").send(meuHtml)
})COPIAR CÓDIGO
Após copiar, basta colar antes do server.use(router) no final do arquivo.
server.js
// código omitido
server.get('/public/docs', (req, res) => {
 const meuHtml = `
 <h1>Documentação da API</h1>
 <ul>
 <li>GET /livros</li>
 <li>POST /livros</li>
 <li>GET /categorias</li>
 </ul>
 `
 res.status(200).contentType("text/plain").send(meuHtml)
})
server.use(router)
server.listen(8000, () => {
 console.log("API disponível em http://localhost:8000")
})COPIAR CÓDIGO
Temos um servidor que quando recebe o método get na URL com o caminho /public/docs executa o que está dentro da função. No conteúdo dessa função, temos uma variável chamada de meuHtml que possui um cabeçalho com o título "Documentação da API" e uma lista com três elementos.
Ou seja, vamos informar a pessoa que estiver lendo que há três rotas principais: GET /livros, POST /livros e GET /categorias. E salvamos esse conteúdo da função na variável meuHtml. Na última linha da função, temos a variável res de response (resposta), onde setamos a resposta para o status 200 e como não desejamos que seja um JSON colocamos o tipo do conteúdo (contentType) como texto, e por fim, enviamos o meuHtml.
Com isso, o meuHtml será o corpo da mensagem HTTP que será enviado como resposta. Teclamos "Ctrl + S" para salvar, e vamos ao terminal onde teclamos "Ctrl + C" para parar a aplicação, e depois rodamos o seguinte comando:
npm run start-authCOPIAR CÓDIGO
Ao teclarmos "Enter", obtemos:
json-server-api@1.0.0 start-auth
node server.js
API disponível em http://localhost:8000
Aparentemente deu certo, e a API está disponível.
Vamos verificar pelo Postman se conseguimos realizar uma requisição para a URL http://localhost:8000/public/docs.
http://localhost:8000/public/docsCOPIAR CÓDIGO
Logo após, clicamos no botão "Send". Como retorno no corpo da resposta, obtemos:
 <h1>Documentação da API</h1>
 <ul>
 <li>GET /livros</li>
 <li>POST /livros</li>
 <li>GET /categorias</li>
 </ul>COPIAR CÓDIGO
Clicando na seta ao lado da palavra "Body" e depois em "Headers" para visualizarmos os cabeçalhos. Na primeira coluna temos o content type como sendo um text/plain (segunda coluna), exatamente como determinamos no JavaScript.
Para verificar se funciona, acessamos o navegador no endereço localhost:8000/public/docs e teclamos "Enter". Como retorno, teremos:
 <h1>Documentação da API</h1>
 <ul>
 <li>GET /livros</li>
 <li>POST /livros</li>
 <li>GET /categorias</li>
 </ul>COPIAR CÓDIGO
A mesma estrutura HTML crua que tivemos como retorno no Postman. Por algum motivo, o navegador não está entendendo que esse texto é um HTML. Precisamos especificar melhor, parece que apenas informar que não é um JSON não é o suficiente.
Voltando ao código, ao invés de colocarmos o contentType() para texto plano, colocamos para text/html. Assim informamos de forma explícita para o navegador que o conteúdo enviado é um HTML.
server.js
// código omitido
server.get('/public/docs', (req, res) => {
 const meuHtml = `
 <h1>Documentação da API</h1>
 <ul>
 <li>GET /livros</li>
 <li>POST /livros</li>
 <li>GET /categorias</li>
 </ul>
 `
 res.status(200).contentType("text/html").send(meuHtml)
})
// código omitidoCOPIARCÓDIGO
Salvamos essa alteração e no terminal digitamos "Ctrl + C" para parar a aplicação. Logo após, rodamos npm run start-auth novamente.
Voltando ao Postman, clicamos em "Send" para testar. Observe que agora temos o nosso content type como text/html. Logo após conferir isso, podemos ir no navegador e atualizar a página.
Há situações que não irão funcionar mesmo atualizando, porque há um cache no navegador. Para arrumar isso, basta teclar "Ctrl + Shift + R".
Observe que agora temos o título "Documentação da API" e abaixo listado os três caminhos principais:
Documentação da API
· GET/livros
· POST/livros
· GET/categorias
Com o content type certo, informamos ao navegador em qual formato desejamos visualizar o conteúdo da página.
Formato dos dados
Em suma, o formato dos dados é determinado pelo cabeçalho Content-Type (formato do corpo da mensagem), que segue uma regra definida. Há um outro cabeçalho chamado de Accept (utilizado na requisição), usado quando um cliente deseja informar um servidor que quer a resposta em um formato específico. Se desejamos em JSON, por exemplo, informamos que aceitamos uma resposta no formato application/json.
Com isso, finalizamos mais uma aula do curso de HTTP.
MÓDULO 06: Conhecendo as evoluções do HTTP
aprendemos sobre os parâmetros GET, POST e REQUEST do HTTP e o deixamos mais seguro.
Porém, tudo o que desenvolvemos passa por iterações e melhorias. Nesta aula, conheceremos as limitações do HTTP na versão 1.1 e as soluções apresentadas na versão número 2.
Nas camadas da Internet, temos as Física na base e a Enlace acima que é nosso wi-fi por exemplo. Depois, temos a rede que trata dos endereços e IPs, além das camadas de Transporte e Aplicação.
Já conhecemos bastante esta última, afinal é onde acontece o HTTP e o HTTPS, browser, servidores e tudo o que usamos até agora.
Nesta aula, abordaremos mais a cama de Transporte que pega as mensagens do HTTP e leva do servidor ao cliente.
Aprendemos que tanto o HTTP/1.1 quanto o HTTP/2 trabalham em cima do TCP.
As maiores diferenças entre esses dois protocolos é que o primeiro deixa a desejar as requisições sequenciais, ou seja, cada vez que fazemos um REQUEST, temos que esperar terminar para começar o outro no contexto de uma conexão TCP, que é o canal por onde as mensagens passam.
Conseguiremos verificar que não acontecem ao mesmo tempo abrindo a interface do nosso debugger clicando com o botão direito sobre a página inicial do AluraBooks para selecionar "Inspect".
Clicando na aba "Network", atualizaremos a página para vermos as diversas requisições sendo feitas. clicando em "localhost" na lista lateral esquerda da aba, abriremos os detalhes e veremos mais diversas imagens em sequência.
Conforme avançamos pelos itens que tiveram requests, perceberemos alterações nos destaques da parte superior. Cada uma das linhas horizontais significa uma conexão TCP.
No HTTP/1.1, temos que esperar cada requisição ao terminar para fazermos outras, então o navegador cria várias conexões em paralelo para permitir que consigamos fazer requests simultâneas.
Mas pode funcionar melhor, então iremos inspecionar o HTTP/2 para entendermos a solução de multiplexação em que pega requisições que acontecem em paralelo e juntá-las em uma mesma conexão TCP, melhorando a performance da aplicação.
Para isso, habilitaremos o HTTPS, pois como o HTTP/2 é mais moderno, a segurança está embutida. Usaremos o comando que já conhecemos do ssl para criarmos um certificado e uma chave.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crtCOPIAR CÓDIGO
Colaremos no Terminal e executaremos.
Em seguida, nos pedirá os dados do certificado, e completaremos apenas com BR mesmo. se digitarmos ls em seguida, veremos o server.crt e o server.key.
Além de criarmos a identidade do certificado, instalaremos a biblioteca spdy que nos permitirá usar o HTTP/2.
npm i spdyCOPIAR CÓDIGO
Depois, geraremos uma pasta "build" atualizada em nossa aplicação, que é como se empacotássemos a aplicação para produção.
Para isso, aplicaremos o comando npm run build e aguardaremos a compactação na pasta com tudo que precisamos para o deploy.
Em seguida, criaremos o servidor que serve o conteúdo da pasta "build" usando HTTP/2.
Abrindo o VSCode, veremos a pasta "curso-react-alurabooks" importada na lista lateral esquerda, clicaremos com o botão direito do mouse para criarmos o novo arquivo server_http2.js.
O conteúdo será:
const spdy = require("spdy")
const express = require("express")
const fs = require("fs")
const app = express()
app.use(express.static("build"))
spdy.createServer(
 {
 key: fs.readFileSync("./server.key"),
 cert: fs.readFileSync("./server.crt")
 },
 app
).listen(3002, (err) => {
 if(err){
 throw new Error(err)
 }
 console.log("Listening on port 3002")
})COPIAR CÓDIGO
Diferente de anteriormente, desta vez estaremos passando a pasta "build" como parâmetro para dizer que será a partir dele que nossos arquivos serão servidos.
Por fim, o mais importante é o spdy que permitirá servir conteúdos através do protocolo HTTP/2.
Salvaremos e voltaremos ao Terminal para executarmos o arquivo com ls e node server_http2.js. Depois, abriremos o browser com uma nova aba no endereço "https://localhost:3002".
Pode ser que recebamos um alerta, afinal nosso certificado não é válido para proteger um site depois que já estiver em produção. Iremos ignorar e prosseguir.
Na página inicial do ALuraBooks, inspecionaremos o código na aba "Network" e veremos os títulos dos conteúdos que estão aparecendo em cada coluna.
Clicando com o botão direito sobre "Status", selecionaremos "Protocol" para habilitarmos o tipo de protocolo usado. Ao recarregarmos a página, veremos que será preenchida por "h2".
Observando a linha do tempo acima, veremos que está bem diferente da que era apresentada usando HTTP/1.1 originalmente. Ou seja, melhoramos a performance.
Portanto, usando HTTP/2, conseguiremos multiplexar e fazer várias requisições ao mesmo tempo dentro de uma ou pelo menos uma quantidade menor de conexões TCP, economizando recursos e deixando mais rápido.
Como vimos no formato das mensagens, o HTTP/1.1 utiliza cabeçalhos textuais como Accept-Ranges: bytes, enquanto o HTTP/2 tem o mesmo cabeçalho porém com as letras minúsculas apenas.
Isso acontece porque no HTTP/2 temos o mecanismo de compactação de cabeçalho, em que o que era legível em formato de texto passa por um algoritmo de compressão e se torna um cabeçalho binário que pode ser enviado pela rede e economizar recursos.
Por fim, a última diferença entre os protocolos é que o HTTP/1.1 possui request obrigatório, então sempre que o cliente quer obter dados, precisará fazer uma requisição ao servidor, afinal é o que aprendemos sobre arquitetura do HTTP.
Porém, observando nosso projeto novamente na tela de debug, há muitas informações retidas, então sempre que formos fazer um request pelo "localhost", com certeza precisaremos de todas as imagens que fazem parte do front-end.
Mas o servidor poderia já saber isso e ser mais "proativo" e mandar as informações ao cliente. É exatamente isso que o HTTP/2 faz através da feature chamada server push, que deixa o servidor mais "inteligente".
Como a web não pára de evoluir, a seguir conhecemos a versão mais nova do HTTP.
Nesta aula, falaremos sobre o HTTP/3 e suas vantagens.
Na camada de transporte, falaremos sobre a variação do UDP usada pelo HTTP/3, chamada de protocolo QUIC que garantirá que a mensagem chegará ao destino e que a Internet não seja "inundada" de dados, pois o TCP possui alguns mecanismos de controle de fluxo.
Ao mesmo tempo que protege, deixa as conexões mais lentas. Além disso, o TCP é um protocolo clássico assim como o UDP que já estão desenvolvidos há bastante tempo e são bem suportados por todos os navegadores, servidores e dispositivos.
Já o QUIC é uma evolução do UDP criado com o objetivo de aprimorá-lo, afinal é possível que uma mensagem não chegue. Às vezes não há problema, como no caso de ver um filme online e perderapenas um dos milhares de frames.
Porém, não funciona tão bem com o HTTP usando UDP diretamente, pois pode ser que o servidor não receba a resposta. Então as melhorias aplicadas ao QUIC resolvem esse problema também.
Como é mais novo, já existia HTTPS que roda "em cima" do TLS, então já vem embutido e permite criar conexões mais seguras. Portanto, há diversas vantagens em utilizar o QUIC.
Em comparação com HTTP/1.1 e HTTP/2 em que é necessária uma conexão TCP, depois TLS que permite o HTTPS entre cliente e servidor para finalmente pegar dados seguros, o HTTP/3 substitui o TCP e já inclui o TLS, então faz tudo de uma só vez.
Como criptografa as mensagens mais rapidamente, consegue mandar mensagem HTTPS antes.
Para vermos sites que o usam, acessaremos "google.com" no navegador e iremos inspecionar.
Na aba "Network", recarregaremos a página e, com a coluna de protocolo já habilitada, veremos o conteúdo "h3". Portanto, o próprio Google já está usando.
Infelizmente ainda não temos todas as bibliotecas disponíveis para HTTP/3 em todas as linguagens, afinal ainda está em estágio experimental.
Mas de qualquer maneira, é sempre importante nos familiarizarmos com as ferramentas do futuro para nos prepararmos para usar.
Para saber mais: as versões novas do HTTP já estão sendo usadas?
Nós aprendemos sobre as melhorias trazidas pelas novas versões do HTTP, agora vamos aprender um pouco mais sobre o uso delas na prática.
De acordo com o site W3Tech, o HTTP/2 já está sendo usado por quase 40% de todos os sites da Internet. Sites populares que utilizam o HTTP/2 incluem: google.com, microsoft.com, e netflix.com. Além disso, o mesmo site sugere que o HTTP/3 é usado por 25% dos sites na Internet. Trata-se de uma adoção bastante rápida, considerando que o HTTP/2 foi publicado como padrão oficial em 2015, e o HTTP/2 em Junho de 2022. Vale lembrar, é claro, que empresas que desenvolvem tanto servidores quanto navegadores (como é o caso do Google), já vinham usando as novas versões mesmo antes de elas serem publicadas oficialmente.
Agora, voltando nossa atenção para o lado prático, várias linguagens e frameworks já suportam as novas versões do HTTP, confira alguns exemplos abaixo:
· No Java, é possível utilizar o HTTP/2, por exemplo, habilitando um módulo no framework Spring Boot;
· No Python, é possível utilizar o pacote hypercorn para habilitar o HTTP/2 e o HTTP/3 no framework Django;
· E claro, podemos também utilizar o HTTP/2 no NodeJS com o pacote spdy, como fizemos em um vídeo anterior.
É interessante notar a evolução rápida nos padrões: há poucos anos o HTTP/2 foi inventado, e agora já temos quase metade da Internet utilizando-o.
Por outro lado, não devemos esquecer que, por mais que se adicione otimizações e melhorias, os princípios básicos continuam os mesmos:
· O HTTP é um protocolo que segue o modelo request-response;
· Ele funciona na camada de aplicação;
· As mensagens são divididas em cabeçalho e corpo;
· Temos métodos nas requisições, e status codes nas respostas.
Portanto, lembre-se que todo o conhecimento que você adquiriu nesta aula, é um complemento, pois na prática você estará utilizando todas as características do HTTP que estudamos ao longo do curso.