Por que todo dev deveria entender HTTP, mesmo sem trabalhar com Front-end?

Quando a gente começa a ouvir falar de HTTP, é bem fácil associar o assunto a navegador, site e Front-end.

Só que basta começar a trabalhar com APIs, Back-end ou integrações entre sistemas para perceber que HTTP está em muito mais lugares do que parece.

E entender pelo menos o básico pode evitar aquele clássico momento de olhar para um 404, 401 ou 500 e pensar: “Tá... e agora?”

Mas afinal, o que é HTTP?

Sem complicar: HTTP é um protocolo que define algumas regras para a comunicação entre cliente e servidor.

Basicamente, alguém faz uma requisição e alguém devolve uma resposta.

Imagine que uma aplicação precisa consultar os dados de um cliente:

Cliente → Requisição HTTP → Servidor

Depois:

Servidor → Resposta HTTP → Cliente

E esse cliente não precisa ser necessariamente uma tela. Pode ser um aplicativo, outro Back-end ou até outro serviço.

É justamente por isso que HTTP não é assunto só de Front-end.

GET, POST e PUT: três que você vai encontrar bastante

Existem vários métodos HTTP, mas alguns aparecem o tempo todo.

GET — quero buscar alguma coisa

Imagine uma API de contas:

GET /contas/123

É como se a aplicação estivesse dizendo:

“Servidor, me devolve os dados da conta 123.”

O GET é muito usado para consultar informações.

POST — quero criar alguma coisa

Agora imagine o cadastro de um cliente:

POST /clientes

Os dados desse cliente podem ser enviados no body da requisição.

Nesse caso, estamos basicamente dizendo:

“Servidor, quero criar um novo cliente com esses dados.”

PUT — quero atualizar alguma coisa

Agora o cliente alterou alguma informação:

PUT /clientes/123

Aqui queremos atualizar um recurso que já existe.

Também existe o PATCH, normalmente usado quando queremos fazer uma atualização parcial.

E ainda temos DELETE, HEAD, OPTIONS e outros. Não precisa sair decorando todos. O mais importante no começo é entender o que aquela requisição está tentando fazer.

E aqueles números? 200, 404, 500...

Outra coisa que aparece bastante quando trabalhamos com HTTP são os códigos de status.

Eles ajudam a contar o que aconteceu com aquela requisição.

Alguns que vale a pena conhecer:

• 200 OK — deu certo.
• 201 Created — algo foi criado com sucesso.
• 400 Bad Request — existe algum problema na requisição enviada.
• 401 Unauthorized — falta uma autenticação válida.
• 403 Forbidden — você não tem permissão para acessar aquilo.
• 404 Not Found — o recurso não foi encontrado.
• 500 Internal Server Error — alguma coisa deu errado no servidor.

Quando começamos a entender esses códigos, investigar um problema fica bem menos misterioso.

Uma dica: antes de mudar o código, olhe a conversa

Quando uma chamada para uma API não funcionar, antes de sair alterando código, vale fazer algumas perguntas:

> Qual método estou usando?

> Era para ser GET e estou enviando POST?

> Estou chamando o endereço certo?

> O endpoint realmente existe?

> O que estou enviando?

> Está faltando algum dado no body ou algum header obrigatório?

> O que o servidor respondeu?

> Qual foi o status? Veio alguma mensagem junto?

Parece simples, mas às vezes a própria resposta HTTP já está dando uma pista enorme de onde está o problema.

Para consultas rápidas no dia a dia, a documentação de HTTP da MDN Web Docs também é uma ótima fonte para deixar por perto.

Recomendação de livro: HTTP: The Definitive Guide

Autores: David Gourley, Brian Totty, Marjorie Sayer, Sailu Reddy e Anshu Aggarwal.

E você: usa os códigos HTTP só para encontrar o erro ou para entender o que aconteceu?