HTTP: Desmistificando o protocolo da Web

HTTP: Desmistificando o protocolo da Web
gabriel-ferreira
gabriel-ferreira

Compartilhe

No amplo cenário digital em que vivemos, há um elemento que desempenha um papel fundamental na World Wide Web, possibilitando a interação, o compartilhamento de informações e a navegação pela internet. Estamos falando do protocolo HTTP.

Embora utilizemos a internet de forma rotineira, nem sempre damos a devida atenção ao importante papel que o HTTP desempenha em nossas experiências online. Continue a leitura para entender o que é protocolo http, como ele atua e por que é importante para o funcionamento da internet.

Imagem de destaque #cover

O que é HTTP?

HTTP é a sigla para Hypertext Transfer Protocol, que em português significa Protocolo de Transferência de Hipertexto. Trata-se de um protocolo de comunicação utilizado para a transferência de informações na World Wide Web (WWW) e em outros sistemas de rede.

Ele é a base da comunicação na internet e permite que os navegadores solicitem páginas da web e outros recursos de servidores, bem como enviem informações de volta para esses servidores.

Dessa forma, HTTP é um protocolo, uma forma de conversa entre duas máquinas, que permite transferir um hiper-texto de um lado a outro. Daí a razão do nome “Hyper Text Transport Protcolo”.

É o protocolo por trás da web que te permite comprar passagens de avião pela internet, conversar com amigos pelas redes sociais, assistir e enviar vídeos para as pessoas. 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. Para compreender melhor o HTTP, é importante entender como o navegador web funciona.

Banner da Escola de Programação: Matricula-se na escola de Programação. Junte-se a uma comunidade de mais de 500 mil estudantes. Na Alura você tem acesso a todos os cursos em uma única assinatura; tem novos lançamentos a cada semana; desafios práticos. Clique e saiba mais!

Recursos, URLs e URIs

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 sintaxe 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 elementos com os quais eu quero interagir, tais como: imagens, páginas, arquivos, e vídeos. Neste caso, o recurso é a página inicial do site pomadasparabigode.com, normalmente um HTML.

Imagine a seguinte URL, que representa uma fictícia Pomada do Bem: http://pomadasparabigode.com/produto/pomada-do-bem-10773

Podemos quebrar ela em 3 partes:

URL Scheme

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, mailto. Tudo que vier depois de "://" é específico do protocolo que estiver sendo utilizado.

Host

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.

URL Path

/produto/pomada-do-bem-10773 é o que chamamos de URL Path (caminho da URL). O servidor irá identificar qual é o recurso específico 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, que provavelmente aponta para um arquivo físico do servidor, uma foto em formato jpg;
  • Já no caso da URL http://pomadasparabigode.com/listar-pomadas, possivelmente 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.

Números de porta

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

Esse número 80 representa o número da porta que o servidor está usando para “ouvir” requisições HTTP. A porta 80 é a padrão e é opcional no caso do uso do endereço em um navegador, 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. O 443 aparece para o https.

Query strings

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

Tudo o que vem depois da “?” é o que chamamos de query string. Nesse caso: ?nome=pomadalegal. 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 “&”, como em ?nome=pomadalegal&tipo=2&categoria=bigodesruivos:

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 descricao 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]

Media Types

Um recurso pode ser várias coisas diferentes: imagens, arquivos HTML, XML, vídeos e muitos mais. Para que um servidor possa servir um recurso e para o cliente poder consumi-lo apropriadamente, as partes envolvidas (cliente e servidor) têm de ser específicas e precisas quanto ao tipo do recurso. Afinal, não faz o menor sentido que meu navegador tente renderizar como imagem um arquivo XML, certo?

Quando um servidor responde uma requisição HTTP, ele devolve o recurso e o seu tipo - chamado de Content-Type(também conhecido como media type). Para especificar tipos de recurso, o HTTP usa outro protocolo(que inicialmente foi feito para comunicação através de e-mail) chamado MIME: Multipurpose Internet Mail Extensions.

O content-type tem duas partes: tipo e subtipo. Por exemplo:

  • Um servidor pode devolver uma imagem no formato png. O content-type da resposta viria como image/png;
  • Se fosse um jpg, o content-type seria image/jpg;
  • E se fosse um arquivo html? text/html;
  • E um json? text/json.

O navegador olha o Media Type para saber o que fazer com um arquivo.

Content Type Negotiation

Como já falamos, um recurso pode ter diferentes representações. Vamos pegar como exemplo a URL que representa o manual de como cuidar do seu bigode:

http://pomadasparabigode.com/comocuidardoseubigode

Este manual poderia, por exemplo, ter diferentes representações no site para diferentes idiomas. Poderia até ser disponibilizado em diferentes formatos: PDF, DOC, html. Neste caso, seria o mesmo recurso, mas em formatos diferentes.

Como o servidor vai saber em que formato deverá enviar o recurso? É aí que entra o mecanismo de Content Negotiation especificado pelo protocolo HTTP: quando um cliente faz uma requisição, ele pode especificar quais Media Types ele aceita.

Desta forma, aplicações diferentes podem solicitar o mesmo recurso - mas em formatos diferentes. Se o servidor irá conseguir devolver o recurso naquele formato, já é outra conversa, que cabe a quem desenvolver o serviço que roda no servidor.

O processo Request-Response

Se você chega e me pergunta: Qual a próxima turma de C# na escola Caelum?

Para que eu possa responder essa pergunta corretamente, são necessárias algumas coisas:

  • Eu preciso entender a sua pergunta. Se você me perguntar em um idioma que não conheço, provavelmente não conseguirei te dar uma resposta;
  • Preciso de acesso a algum lugar que conste as próximas turmas da Caelum.

O HTTP funciona mais ou menos desta mesma forma: um cliente precisa de um recurso que está em outro computador. Então, o cliente faz uma requisição (http request) para um servidor usando uma linguagem e vocabulário que espera que o servidor consiga entender. Se o servidor conseguir entender sua requisição e tiver o recurso disponível, ele irá responder com uma resposta(response). Caso o servidor entenda a requisição, mas não tenha o recurso, provavelmente ele vai responder que não tem. Caso ele não entenda a requisição, você pode não ter resposta.

Request http e Response são dois tipos de mensagem diferentes quando falamos de HTTP. A especificação HTTP diz exatamente o que podemos colocar dentro de cada um destes tipos de mensagem para que todos que "falem" o idioma HTTP, e consigam trocar informações corretamente.

Uma requisição HTTP tem o seguinte formato:

request

E uma resposta HTTP:

response

Então, resumidamente, não existe nada mágico quando você digita um endereço no navegador: ele abre uma conexão com o servidor em questão e envia para ele um monte de texto seguindo regrinhas especificadas pelo protocolo.

E aí curtiu? Então se atente para o próximo post! E se quiser saber ainda mais sobre HTTP, confira:

Veja outros artigos sobre Programação