Perguntas sobre API REST testam se você consegue projetar uma interface que outras pessoas vão usar sem surpresas. Abaixo estão 20 perguntas com respostas, do básico aos detalhes de design que aparecem em entrevistas de backend e full-stack. Para as regras de métodos HTTP, seguimos as definições da RFC 9110.
Fundamentos
1. O que é REST?
REST é um estilo arquitetural para sistemas em rede, construído em torno de recursos identificados por URLs, manipulados com um pequeno conjunto de operações padrão e descritos por representações como JSON. Uma API REST é stateless: cada requisição carrega o que o servidor precisa para processá-la, então qualquer servidor pode atender qualquer requisição.
2. O que torna uma API "RESTful" na prática?
- Substantivos para recursos nas URLs, como /orders/42, e não verbos como /getOrder
- Métodos HTTP padrão para as ações
- Códigos de status significativos
- Requisições stateless
- Representações e formatos de erro consistentes
Na entrevista, diga que poucas APIs reais seguem todas as restrições do REST e que você busca um comportamento previsível.
3. Para que servem os principais métodos HTTP?
| Método | Uso | Seguro | Idempotente |
|---|---|---|---|
| GET | Ler um recurso | Sim | Sim |
| POST | Criar um recurso ou disparar uma ação | Não | Não |
| PUT | Substituir um recurso | Não | Sim |
| PATCH | Atualizar parcialmente um recurso | Não | Não garantido |
| DELETE | Remover um recurso | Não | Sim |
"Seguro" significa que a requisição não altera o estado do servidor. "Idempotente" significa que enviá-la várias vezes tem o mesmo efeito de enviá-la uma vez.
4. O que significa idempotente, e por que isso importa?
Se uma requisição for repetida, o estado final é o mesmo de depois de uma requisição. Isso importa porque as redes falham. Se um cliente der timeout em um PUT, ele pode tentar de novo sem medo. Um POST que cria um pedido poderia criar dois, então as APIs costumam aceitar uma chave de idempotência: o cliente envia uma chave única, e o servidor retorna o resultado armazenado se vir a chave de novo.
5. PUT ou PATCH?
PUT substitui o recurso inteiro pelo corpo que você envia, e os campos que você omite são apagados ou redefinidos. PATCH altera apenas os campos que você envia. Use PATCH para atualizações pequenas e PUT quando o cliente tem a representação completa.
Códigos de status e erros
6. Quais códigos de status você usa, e quando?
| Código | Uso |
|---|---|
| 200 | Sucesso com um corpo |
| 201 | Criado, com um cabeçalho Location para o novo recurso |
| 204 | Sucesso sem corpo, como em um delete |
| 400 | A requisição está malformada ou é inválida |
| 401 | Não autenticado |
| 403 | Autenticado, mas sem permissão |
| 404 | Recurso não encontrado |
| 409 | Conflito com o estado atual, como uma duplicata |
| 422 | Bem formada, mas falha na validação |
| 429 | Requisições demais |
| 500 | Erro no servidor |
| 503 | Serviço indisponível |
Uma pergunta de acompanhamento frequente é a diferença entre 401 e 403. 401 significa "não sei quem você é", e 403 significa "sei quem você é, e você não pode fazer isso".
7. Como uma API deve retornar erros?
Use o código de status correto e um corpo consistente. Um bom corpo de erro tem um código estável legível por máquina, uma mensagem para humanos e, no caso de erros de validação, quais campos falharam. Não vaze stack traces nem detalhes internos para os clientes.
8. Como você lida com validação?
Valide no servidor mesmo que o cliente também valide. Retorne todos os problemas de uma vez quando puder, para que o usuário não precise corrigi-los um a um, e use 400 ou 422 de forma consistente.
Design
9. Como você projeta URLs para relacionamentos?
Aninhe quando o filho só faz sentido dentro do pai, como /users/7/orders. Mantenha o aninhamento raso. Depois de um ou dois níveis, exponha o filho diretamente, como /orders/42, e filtre com parâmetros de consulta, como /orders?userId=7.
10. Como você pagina uma lista?
| Método | Como funciona | Trade-off |
|---|---|---|
| Offset e limit | ?offset=40&limit=20 | Simples, mas lento em tabelas grandes e pode pular ou repetir itens quando os dados mudam |
| Cursor | ?after=<token>&limit=20 | Estável e rápido, mas você não consegue pular para a página 50 |
| Número da página | ?page=3 | Fácil para UIs, com os mesmos problemas do offset |
A paginação por cursor costuma ser a resposta para dados grandes ou que mudam rápido. Retorne o próximo cursor e uma indicação de se existem mais resultados.
11. Como você filtra e ordena?
Use parâmetros de consulta, como ?status=open&sort=-created_at. Coloque em uma lista de permissões os campos que você aceita, para evitar expor colunas sem índice ou sensíveis e manter as consultas rápidas.
12. Como você versiona uma API?
| Abordagem | Exemplo | Observação |
|---|---|---|
| Na URL | /v2/orders | Simples e visível |
| Em um header | Accept: application/vnd.example.v2+json | URLs mais limpas, mais difícil de testar no navegador |
| Parâmetro de consulta | ?version=2 | Fácil, mas fácil de esquecer |
Independentemente do que escolher, evite mudanças que quebram compatibilidade dentro de uma versão. Adicionar campos geralmente é seguro; remover ou renomear campos não é.
13. O que é HATEOAS?
As respostas incluem links para ações relacionadas, para que o cliente possa descobrir o que pode fazer em seguida em vez de codificar URLs na mão. Faz parte da definição de REST, mas poucas APIs implementam isso por completo. Diga que você conhece o conceito e que a maioria dos times usa documentação e uma descrição OpenAPI no lugar.
Segurança e desempenho
14. Como você autentica uma API?
As escolhas comuns são chaves de API para uso simples entre servidores, tokens bearer como JSON Web Tokens e OAuth 2.0 quando um usuário concede a um app acesso aos seus dados. Use sempre HTTPS. Mantenha segredos fora das URLs, já que as URLs acabam nos logs.
15. Qual é a diferença entre autenticação e autorização?
Autenticação é provar quem você é. Autorização é decidir o que você tem permissão para fazer. Elas falham de formas diferentes: um token ausente ou inválido é 401, e um token válido sem permissão é 403.
16. Como você protege uma API contra abusos?
Rate limiting por chave ou por IP, limites de tamanho de requisição, validação de entrada, timeouts e monitoramento de tráfego incomum. Retorne 429 com um header Retry-After para que os clientes saibam quando tentar de novo.
17. Como o cache HTTP funciona para APIs?
As respostas podem carregar headers Cache-Control que dizem por quanto tempo uma resposta pode ser reutilizada. Um ETag identifica uma versão da resposta. O cliente o envia de volta em If-None-Match, e o servidor responde 304 Not Modified sem corpo se nada mudou. Isso economiza banda e carga.
18. O que é CORS?
Os navegadores bloqueiam uma página web de ler respostas de uma origem diferente, a menos que o servidor permita. O servidor envia headers como Access-Control-Allow-Origin para dizer quais origens podem ler suas respostas. Isso é aplicado pelo navegador, não pelo servidor, então não protege uma API de clientes que não são navegadores.
Prática
19. REST ou GraphQL ou gRPC?
| Bom para | Custo | |
|---|---|---|
| REST | APIs públicas simples, cacheáveis e amplamente compreendidas | Over-fetching e muitas idas e voltas para telas complexas |
| GraphQL | Clientes que precisam escolher exatamente os campos e combinar dados em uma única requisição | Mais complexidade no servidor e cache mais difícil |
| gRPC | Chamadas internas rápidas entre serviços com contratos rígidos | Menos amigável para navegadores e uso público |
A melhor resposta cita uma situação, não um vencedor.
20. Como você documenta e testa uma API?
Descreva-a com uma especificação OpenAPI, que pode gerar documentação e código de cliente. Teste em três níveis: testes unitários para a lógica, testes de integração contra um banco de dados real e testes de contrato para pegar mudanças que quebram compatibilidade. Teste também os casos de falha, como entrada inválida e tokens expirados.
Como se preparar
- Saiba projetar uma API pequena no quadro branco, como uma lista de tarefas ou um sistema de pedidos, com URLs, métodos, códigos de status e uma resposta de erro.
- Domine idempotência e paginação de cor. São os assuntos que mais aparecem.
- Prepare uma história sobre uma API que você construiu ou usou, e um erro que você evitaria da próxima vez.
Para praticar temas relacionados, veja nossos guias de perguntas de entrevista sobre Spring Boot, perguntas de entrevista sobre Node.js, perguntas de entrevista sobre system design e perguntas de entrevista sobre redes de computadores.
Pratique em voz alta e com suas próprias palavras. Uma transcrição depois mostra onde você se enrolou ou fugiu do ponto. Siga as regras do empregador sobre ferramentas de IA em qualquer entrevista ou avaliação ao vivo.
Pratique suas respostas com YesToTheOffer
Ensaiar em voz alta, obter respostas construídas a partir do seu próprio currículo e revisar sua transcrição depois. 30 minutos grátis, sem assinatura.
