Você já usou uma API hoje e provavelmente nem percebeu. Abriu o app do banco, conferiu a previsão do tempo, deu scroll no feed — tudo isso é um monte de aplicativo conversando com servidor via API. E na esmagadora maioria das vezes, essa conversa segue um estilo chamado REST. Bora abrir a caixa preta.
API é só um garçom
Esquece a sigla (Application Programming Interface) por um segundo. Pensa num restaurante. Você não vai até a cozinha fritar seu próprio ovo — você fala com o garçom, ele leva o pedido, volta com o prato. A API é o garçom: um intermediário com um cardápio fixo de coisas que dá pra pedir.
O seu app (o cliente) pede algo. O servidor prepara e devolve. Você nunca toca no banco de dados direto, nunca vê a cozinha. Só conhece o cardápio — os endereços que dá pra chamar e o que cada um faz. Essa separação é o que deixa tudo sustentável: o time do backend pode reformar a cozinha inteira e, enquanto o cardápio continuar o mesmo, seu app nem fica sabendo.
HTTP: o idioma da conversa
Toda essa troca acontece por HTTP, o mesmo protocolo do seu navegador. E cada pedido carrega um método, que é o verbo da ação:
- GET — buscar dados. "Me mostra os usuários." Não muda nada.
- POST — criar. "Cadastra esse usuário novo."
- PUT — atualizar. "Troca os dados desse usuário."
- DELETE — apagar. "Remove esse usuário."
A sacada é que o método deixa a intenção explícita. GET /usuarios e DELETE /usuarios/42 batem na mesma ideia de recurso, mas fazem coisas opostas — e qualquer dev que ler isso entende na hora, sem precisar de documentação. Além do método e da URL, o pedido leva headers (informações extras, tipo quem você é e que formato você aceita) e, em POST e PUT, um corpo com os dados que você está mandando.
Status codes: o servidor respondendo na lata
Pra cada pedido, o servidor devolve um número de três dígitos dizendo como foi. Você não precisa decorar todos, só o padrão das faixas:
- 2xx — deu certo.
200 OK(aqui está),201 Created(criei o que você pediu). - 4xx — o erro foi seu.
400 Bad Request(você mandou algo torto),401 Unauthorized(cadê o login?),403 Forbidden(logado, mas sem permissão),404 Not Found(isso não existe). - 5xx — o erro foi do servidor.
500 Internal Server Error(a cozinha pegou fogo, não foi culpa sua).
Só de ler o código você já sabe pra que lado olhar. Levou 401? Confere o token. Levou 500? Relaxa, o problema é do outro lado — e do time do backend.
Recursos e JSON: o cardápio e o prato
Em REST, tudo gira em torno de recursos — os substantivos do seu sistema: usuários, pedidos, produtos. Cada recurso tem uma URL, e a URL é uma trilha lógica: /usuarios é a lista toda, /usuarios/42 é o usuário de id 42, /usuarios/42/pedidos são os pedidos dele. Repara que são substantivos, nunca verbos — quem faz o papel de verbo é o método HTTP.
E o formato em que esses dados viajam quase sempre é JSON. É texto puro, legível por humano e por máquina:
{
"id": 42,
"nome": "Ana",
"ativo": true,
"tags": ["admin", "beta"]
}
Chaves e valores, listas, números, booleanos. É basicamente um objeto do seu código serializado em texto pra atravessar a internet e ser remontado do outro lado.
Stateless e tokens: o servidor tem amnésia
Aqui mora a pegadinha que confunde todo mundo no começo: a API REST é stateless. Ou seja, o servidor não lembra de você entre um pedido e outro. Cada requisição chega do zero, como se fosse a primeira vez. Não existe "mas eu acabei de fazer login no request anterior" — pra ele, request anterior nunca existiu.
Então como o servidor sabe quem é você? Você fala de novo, toda vez. Depois de logar, você recebe um token — uma string longa que funciona como um crachá. Aí, em todo pedido seguinte, você anexa esse token num header:
Authorization: Bearer eyJhbGciOiJIUzI1Ni...
O servidor lê o crachá, confere se é válido e libera (ou barra com um 401). É isso que torna a API escalável: qualquer servidor da fazenda consegue te atender, porque tudo que ele precisa pra saber quem você é vem junto no próprio pedido.
Mão na massa: curl e Postman
Teoria chega. A melhor forma de entender uma API é cutucar ela. Duas ferramentas resolvem sua vida.
O curl já vem no terminal e é direto ao ponto:
curl -X GET https://api.exemplo.com/usuarios/42 \
-H "Authorization: Bearer SEU_TOKEN"
Um POST mandando JSON não é muito mais difícil:
curl -X POST https://api.exemplo.com/usuarios \
-H "Authorization: Bearer SEU_TOKEN" \
-H "Content-Type: application/json" \
-d '{"nome": "Ana", "ativo": true}'
O -X escolhe o método, cada -H é um header, o -d é o corpo. Repara que tá tudo ali: método, URL, token no header, JSON no corpo. É a conversa inteira numa linha.
Já o Postman é a versão com interface gráfica: você preenche URL, escolhe o método num dropdown, monta headers e corpo em campos separados, aperta Send e vê a resposta formatada com o status code piscando na sua cara. Pra explorar uma API nova ou debugar, é imbatível.
Pronto. Agora quando você ler "faz um GET nesse endpoint e passa o token no header", não é mais grego. É só o garçom, o pedido e o crachá. O resto é praticar: pega qualquer API pública, abre o Postman e sai cutucando.
