Desmistificando o protocolo HTTP – parte 1

(Última atualização em: 1 de junho de 2017)

Em um vôo com destino a Belém para dar aula pela Caelum</a,> começo a escrever uma série de N de posts sobre o protocolo HTTP postarei aqui no blog do Alura 🙂

HTTP é o protocolo que te permite comprar passagens de avião pela internet(como comprei para essa viagem), conversar com amigos pelas redes sociais e assistir mandar videos de gatos para sua familia. É o protocolo por trás da World Wide Web. Com ele, é possível que um estudante num café em São Paulo leia um artigo sobre o império mongol que está armazenado em um servidor nos Estados Unidos.

Entender bem o protocolo HTTP pode te ajudar a desenvolver melhores aplicações web e a debugá-las quando as coisas derem errado.

Vamos começar falando da coisa mais importante do protocolo HTTP: os recursos.

Recursos

A parte que conhecemos melhor do protocolo HTTP é o endereço HTTP de um site. Por exemplo, quando quero comprar pomada para o meu bigode, abro o navegador e digito http://pomadasparabigode.com. Meu navegador entende a síntaxe e faz uma requisição para um servidor chamado pomadasparabigode.com.

O endereço http://pomadasparabigode.com é o que chamamos de URL – Uniform Resource Locator(localizador de recurso uniforme). Ela representa um recurso específico na web. Recursos são coisas que eu quero interagir, como: imagens, páginas, arquivos, e videos.
Neste caso, o recurso é a página inicial do site pomadasparabigode.com.

Existem milhões de recursos na internet e consequentemente, milhões de recursos. E cada recurso tem sua URL.
Imagine a seguinte URL, que representa a Pomada do Bem:
http://pomadasparabigode.com/produto/pomada-do-bem-10773

Podemos quebrar ela em 3 partes:
1. http, a parte antes de “://” é o que chamamos de URL Scheme(esquema da URL). O esquema descreve como acessar um recurso em particular. Nesse caso, estamos falando para o navegador usar o Hypertext Transfer Protocol, o HTTP. Existem outros esquemas, tais como: https, TCP, FTP, maito. Tudo que vier depois de “://” é específico do protocolo que estiver sendo utilizado.
2. pomadasparabigode.com é o nome do host(servidor), que seria o nome do computador que armazena nosso recurso. Nosso navegador vai realizar um processo conhecido como DNS Lookup para traduzir pomadasparabigode.com em um endereço de rede. E vai enviar a requisição para esse endereço.
3. /produto/pomada-do-bem-10773 é o que chamamos de URL Path(caminho da URL). O servidor irá identificar qual é o recurso especifico que deve devolver para este caminho quando a requisição chegar.

URLs podem apontar para arquivos físicos, como por exemplo http://pomadasparabigode.com/foto.jpg provavelmente para um arquivo físico do servidor, uma foto em formato jpg.
Já no caso da URL http://pomadasparabigode.com/listar-pomadas provavelmente não aponta para um arquivo físico diretamente. Nesse caso, provavelmente o que vai acontecer é: uma aplicação desenvolvida em alguma tecnologia como ASP.NET, PHP, Rails, Java irá tratar a requisição no servidor, fará uma consulta em um banco de dados e o recurso que será devolvido vai ser construído dinamicamente por esta aplicação.

Hoje em dia, por várias razões, evitamos URLS que apontem diretamente para arquivos. Uma das razões é que quando se fala de SEO, URLs que sejam descritivas funcionam melhor.
Quando o navegador faz uma requisição para um servidor solicitando um recurso, pode ser que para carregar o recurso específico seja necessário carregar recursos adicionais, tais como: imagens, arquivos CSS e Javascript.

Números de porta

http://pomadasparabigode.com:80/listar-pomadas

Esse número 80 aí representa o número da porta que o servidor está usando para “ouvir” requisições HTTP. 80 é a padrão e é opcional, então normalmente você não vê esse 80 nas URLs.
É mais comum especificarmos esta porta quando estamos testando a aplicação em ambiente de homologação/testes.

Query strings

http://pomadasparabigode.com/busca?nome=pomadalegal

Tudo o que vem depois da ? é o que chamamos de query string. Geralmente colocamos na query string informações que serão interpretadas de alguma forma pela aplicação que é executada no servidor.
Não existe uma regra formal de como as query strings são montadas, mas a forma mais comum de utilização é através de pares chave-valor, separados por &:

http://pomadasparabigode.com/busca?nome=pomadalegal&tipo=2&categoria=bigodesruivos

Fragmento

http://pomadasparabigode.com/produto/pomada-especial#descricao

Esse “#descricao” na URL não é interpretado pelo servidor, mas sim pelo navegador do usuário. Depois de carregar o recurso que é especificado através dessa URL, o navegador irá procurar um elemento com o id “conteudo” na página:

e irá posicionar a barra de rolagem a partir do início dele, ou seja, onde começa a descrição do produto.

Resumidamente, uma url pode ser quebrada então no seguinte formato:

[esquema]://[servidor]:[porta]/[caminho]?[querystring]#[fragmento]

E ai, curtiu?
Temos um curso no Alura que te ensina o protocolo HTTP por baixo dos panos 🙂

No próximo post, falarei sobre Media Types e o processo de Request/Response.

Desenvolvedor e criador de conteúdo no grupo Caelum. Host do Alura Live. Sempre aprendendo coisas novas e passando o conhecimento adiante.

  • Giovanni

    Bem legal o post Gabriel, espero ansioso pela segunda parte.

  • Herberto Mauricio

    Muito Bom, teu poste me ajudou muito a entender e tirar as duvidas sobre o Protocolo HTTP, continue e em breve estarei de novo no Brasil (RJ) espero poder o conhecer ou estar em algum curso que estiver ministrando

    • Opa Herberto!

      No RJ vai ser dificil, mas se passar por São Paulo pode vir conhecer a Caelum e o Alura se quiser 😉

  • Bruno Silva

    Show de bola

  • Tem previsão de quando sairá o próximo?

  • Ótimo post Gabriel, poderíamos chamar “/produto/pomada-do-bem-10773” de URI ? Além disso também podemos chamar “query string” de parâmetros certo ?

    Abraços.

    • Poderia chamar de URI sim, Matheus!
      E sim, a query string podem ser os parâmetros também. No fim é a mesma coisa, né? 😀

  • Pingback: Blog do Alura – Desmistificando o protocolo HTTP – parte 2()

Próximo ArtigoRecebendo dados de um formulário HTML com Servlets