O HTTP se tornou a base para a comunicação da internet. Neste post, vou escrever um pouquinho do que aprendi sobre o assunto.
O Hypertext Transfer Protocol (HTTP) é um dos protocolos disponíveis na camada de aplicação, que não possui estado e foi projetado para sistemas distribuídos e colaborativos.
Sua estrutura foi feita olhando para os protocolos da Internet, permitindo que elementos de redes aprimorem ou habilitem suas comunicações entre cliente e servidor, esse modelo de comunicação é chamado de 'client-server'.
Essa comunicação entre cliente e servidor é feita a partir da implementação de outro protocolo conhecido como request-response.
Requisitando informações do servidor
Um request ou requisição é uma mensagem enviada pelo cliente para um servidor em busca de um recurso específico.
A requisição é formada de várias informações para que o servidor consiga entender a solicitação e assim responder com os dados solicitados.
Essas informações são conhecidas como: métodos da requisição, corpos da requisição (opcionais), URL ou URI e cabeçalho.
O que o servidor precisa fazer ?
Os métodos ou verbos da requisição indicam qual ação o servidor deve realizar para responder adequadamente. E estes são os métodos utilizados:
GET: solicita a recuperação de informações do recurso especificado pela URL no servidor;
HEAD: semelhante ao GET, mas solicita apenas os cabeçalhos da resposta, sem o corpo da mensagem;
POST: envia dados ao servidor para criar um novo recurso;
PUT: envia dados ao servidor para atualizar ou substituir um recurso já existente na URL especificada;
DELETE: solicita a exclusão permanente de um recurso específico no servidor;
CONNECT: estabelece uma conexão de túnel com o servidor;
OPTIONS: obtém as opções de comunicação permitidas para um recurso específico no servidor;
TRACE: usado para diagnosticar problemas de rede;
PATCH: envia apenas as alterações para que modificações parciais sejam aplicadas no recurso;
Falarei um pouco mais sobre cada um dos métodos HTTP em outro post sobre APIs 💫 🚀.
Enviando informações para o servidor
Apesar de ser opcional, o corpo da requisição é bem utilizado nos métodos POST, PUT e PATCH e indica as informações adicionais enviadas pelo cliente para recursos específicos no servidor.
Essas informações podem ser enviadas como texto, JSON, XML e até mesmo binários. Tanto o formato quanto a estrutura a serem enviados dependem do tipo de conteúdo e do acordo entre cliente e servidor.
Para indicar o formato do corpo na requisição, podemos incluir no cabeçalho o seguinte valor: Content-Type.
Por exemplo:
Content-Type: application/json
Nesses exemplos, estamos indicando que o corpo da requisição será no formato JSON.
Iguais, mas diferentes: URL e URI
O destino de uma requisição HTTP é chamado de recurso, e estes podem ser identificados como URIs ou URLs.
O termo URI ou Uniform Resource Identifier engloba as URLs e é definido como uma sequência única de caracteres que identifica um recurso lógico ou físico, podendo ser usado para identificar qualquer coisa.
Por exemplo:
https://www.exemplo.com.br/recurso?parametro=valor
Vale lembrar que a estrutura das URIs pode variar dependendo do contexto.
Por sua vez, uma URL ou Uniform Resource Locator é uma forma específica de URI para referenciar um recurso de maneira precisa, contendo as informações necessárias para localização e recuperação na rede.
Por exemplo:
https://meu-site-exemplo.com.br/index.html
Como podemos ver, a URL possui o protocolo, domínio e caminho do recurso específico.
Conhecendo o HTTP header
Assim como a armadura do Homem de Ferro, os cabeçalhos HTTP possuem diferentes módulos e funcionalidades, pois ambos são componentes vitais que permitem a comunicação e fornecem recursos específicos.
Um dos componentes essenciais para as solicitações e respostas do protocolo HTTP são os cabeçalhos ou Headers.
Projetado para ter várias responsabilidades e conter diversas informações relacionadas a diferentes aspectos da comunicação 'client-server', os cabeçalhos têm como característica principal a extensibilidade, que permite definir novos cabeçalhos para atender os novos requisitos.
Aqui tem uma listinha de algumas responsabilidades que um cabeçalho pode ter:
- Controle de cache.
- Autenticação e segurança.
- Negociação de conteúdo.
- Controle de redirecionamento.
- Controle de codificação.
- Controle de conexão.
- Controle de tipo de conteúdo.
- Controle de compressão.
- Controle de acesso.
- Rastreamento e análise.
Além dos citados acima, também temos muitos outros disponíveis e cada um com sua função específica para que a comunicação seja eficiente e segura.
Respondendo a requisição do cliente
Anotações breves sobre respostas HTTP e seus principais elementos.
A resposta HTTP é enviada pelo servidor para o cliente, assim completando o ciclo request-response proposto pelo protocolo HTTP.
Assim como as requisições, as respostas também podem adicionar cabeçalhos, como Content-Type, Last-Modified e muitos outros.
Além dos cabeçalhos, temos outro componente muito importante: o status code.
O status code possui cinco classes:
- 1xx - Informativa
- 2xx - Sucesso
- 3xx - Redirecionamento
- 4xx - Erro do lado do cliente
- 5xx - Erro do lado do servidor
O status code permite que o servidor se comunique com o cliente de forma padronizada sobre o resultado da requisição. Também indica se a requisição foi bem-sucedida, se ocorreu algum problema ou se são necessárias ações adicionais. Portanto, o status code torna-se uma ferramenta importante para o tratamento de erros e permite que o cliente identifique e lide com diferentes situações de falha de forma apropriada.
Alô, quem tá falando ?
O DNS ou Domain Name System é um sistema de nomenclatura, funciona de forma hierárquica e distribuída para qualquer recurso na internet ou em outras redes.
Sua responsabilidade é converter nomes de domínios legíveis para humanos (www.exemplo.com.br) em endereços IP (192.168.0.2), que são legíveis para máquinas.
Construindo um ambiente seguro
Precisamos de mais segurança na hora de enviar informações entre o
clienteeservidor
Com o crescimento da internet e o aumento das transações online, tornou-se evidente que a segurança era uma questão vital. Houve a necessidade de proteger informações sensíveis, como senhas, informações bancárias e outros detalhes pessoais, durante a conversa entre os clientes e os servidores. E para atender a essa demanda, o HTTPS surgiu.
O HTTPS utiliza uma camada de segurança que realiza a criptografia dos dados transmitidos através dos protocolos SSL ou TLS, tornando os dados ilegíveis para quem tenta interceptá-los.
Além dessa camada de segurança, o HTTPS possui um mecanismo de autenticação para verificar a fidelidade do servidor, evitando ataques como: phishing, man-in-the-middle, injeção de conteúdos maliciosos e outros.
Todo pokémon evolui
Um pouquinho sobre as versões do HTTP ao longo do tempo:
HTTP/1.1,HTTP/2eHTTP/3
O HTTP recebeu sua primeira revisão e foi nomeado como HTTP/1.1.
O HTTP/1.1 foi pensado como um protocolo em que as mensagens são enviadas no formato de texto e também introduziu diversas funcionalidades, como conexões persistentes, pipelining, chunked transfer encoding e cabeçalho do host.
Mesmo com todas as inovações apresentadas pelo HTTP/1.1, com o passar do tempo surgiram novas necessidades e então o HTTP/2 apareceu.
Esta versão foi desenvolvida pensando em melhorar a performance da web e superar as limitações de sua versão anterior. Com isso, o novo protocolo HTTP introduziu o formato binário, a multiplexação, o server push, compressão de headers e a priorização de requisições.
O HTTP/2 apresentou uma melhoria muito significativa em relação à versão anterior e foi amplamente adotado por servidores e navegadores.
Contudo, uma nova versão foi apresentada ao mundo: o HTTP/3, originalmente chamado de HTTP-over-QUIC. Esta versão possui redução de latência, priorização de stream e multiplexação, melhorias em segurança e também foi construída para lidar com a mudança de rede de forma eficiente e permitir rápida adaptação a diferentes condições de rede.
QUIC, quem é esse pokémon ?
Você deve ter notado que no nome original do HTTP/3 uma nova palavrinha foi introduzida, o QUIC.
Desenvolvido pelo Google em 2012, o QUIC foi projetado para uso pesado da internet móvel, no qual as pessoas carregam smartphones que mudam constantemente de uma rede para outra à medida que se movem durante o dia. Assim, o QUIC depende do protocolo UDP e não do TCP. Essa dependência faz com que as conexões sejam mais rápidas, resultando em uma experiência melhor para o usuário final.
No fim do dia...
Aprendi a importância do HTTP e como ele impacta a internet.
Também achei várias coisinhas interessantes no meio do caminho, principalmente sobre headers, versões do HTTP, segurança, sessions, cookies e criptografia. Planejo escrever sobre alguns destes assuntos no futuro também.
Espero que te ajude ou pelo menos estimule você a procurar mais sobre o HTTP e assuntos ligados a ele.
Me siga no Twitter, Github ou LinkedIn para acompanhar minhas aventuras no mundo tech 💫.
p.s: todo feedback é bem vindo!
Top comments (0)