Desmistificando o protocolo HTTP – parte 2

(Última atualização em: 6 de junho de 2016)

Este é o segundo post sobre o protocolo HTTP de uma série de N que escreverei aqui 🙂

No primeiro post(que você pode ler aqui), falei basicamente sobre como um recurso pode ser representado através de uma URL.

Neste post, vamos falar um pouco sobre Media Types.

Media Types

Um recurso pode ser várias coisas diferentes: imagens, arquivos HTML, XML, videos e muitos mais. Pra que um servidor possa servir um recurso e para que o cliente possa 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 um 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.
Você pode conferir quais são os Media Types aqui.

O navegador sempre 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 Caelum?

Para que eu possa responder essa pergunta corretamente, são necessárias algumas coisas:
1- 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;
2- 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 um outro computador.
Então, o cliente você faz uma requisição(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 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 consigam trocar infomaçõ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 ai curtiu? Fique atento para o próximo post!
E se quiser saber ainda mais sobre HTTP, temos um curso no Alura que fala especificamente sobre isso 🙂

Autodidata, programa há 10 anos e herdou a profissão do pai, também programador. Atuou 7 anos com .NET em diversos ramos: bancos, seguradoras, agências de marketing, telefonia. Atualmente é instrutor e programador na Caelum. Acredita que todo mundo pode programar e não tem preconceito nenhum com linguagens e tecnologias. Está sempre disposto a aprender e ensinar coisas novas.

Próximo ArtigoAumentando a produtividade no Android com o Butter Knife