API REST no Currículo: Como Descrever Integrações Com Resultado

API REST no currículo costuma aparecer de duas formas: como desenvolvimento de APIs ou como integrações, e as duas dizem coisas diferentes para quem lê. A vaga de back-end quer saber se você desenhou o contrato que outras equipes consumiam ou se apenas chamou um endereço que já estava documentado. Este guia mostra como separar essas experiências, como nomear o esquema de autenticação, como descrever volume e consumidores e como mostrar que a API tinha documentação e versão.

Construir uma API e integrar com uma API de terceiros são linhas diferentes

Escreva que você construiu quando definiu os recursos, as rotas, as regras de validação e o contrato publicado. Escreva que você integrou quando consumiu uma API de outra empresa ou de outra equipe, com a autenticação e os limites que ela impunha. As duas experiências têm valor, e confundi-las é a forma mais rápida de perder credibilidade na primeira pergunta técnica.

Antes: Desenvolvimento e integração de APIs REST.

Depois: Projetei e publiquei a API de consulta de pedidos, usada por três aplicativos internos, com rotas por recurso, validação de entrada e contrato documentado em OpenAPI.

Se você só consumiu endpoints que já existiam, escreva integração e nomeie a API consumida. Consumo não vira criação de contrato, e uma vaga de back-end pleno costuma perguntar qual rota você mudaria primeiro. Quem não mudou nenhuma deve dizer que não mudou. A stack que acompanha a API, como a linguagem e o framework, segue o que o guia de currículo de desenvolvedor back-end descreve.

O esquema de autenticação mostra o que a API protegia, então nomeie o esquema

A autenticação é o trecho do currículo que mostra se você pensou em acesso, e não só em resposta. Nomeie o esquema que você implementou ou consumiu, porque cada um tem um custo de manutenção diferente:

• Chave de API. Um segredo enviado em cada requisição, comum em integrações de servidor para servidor. Cite se você gerou, rotacionou ou revogou chaves, porque é aí que o trabalho aparece.
• JWT. Um token assinado que carrega a identidade e as permissões do usuário. Cite a validação da assinatura e o tempo de expiração, que são os pontos onde a implementação costuma falhar.
• OAuth 2.0. Um protocolo de autorização delegada, usado quando um sistema acessa dados em outro com permissão do usuário. Cite o fluxo específico, como client credentials na comunicação entre serviços, e não apenas o nome do protocolo.

Antes: API com autenticação segura.

Depois: Implementei autenticação por JWT com expiração em quinze minutos e renovação por refresh token, e restringi os endpoints administrativos por papel de usuário.

Se o framework já trazia o mecanismo e você apenas o ligou, escreva que configurou, e não que implementou. A diferença aparece na primeira pergunta sobre como a validação funciona por dentro.

Volume e latência valem quando dizem quem fazia as chamadas

Um número de requisições sem contexto soa como enfeite. O que dá peso é dizer de onde vinha a carga: um aplicativo móvel, um parceiro externo ou um job noturno. Cite o volume no pico ou por dia e, se você mediu, a latência que a aplicação precisava manter.

Antes: API com alto volume de requisições.

Depois: Atendi cerca de 2 mil requisições por minuto no pico, vindas do aplicativo de vendas, com resposta média abaixo de 300 ms, medida no painel de monitoramento do gateway.

Se você não tem o número, não invente um. Descreva a carga pelo uso e pela decisão que ela forçou, como colocar cache numa consulta muito chamada. Uma decisão de desenho diz mais do que um volume que ninguém confirma. Para transformar essa decisão em linha com verbo e efeito, o método de como descrever experiência com resultados e números serve sem mudança.

Versão e documentação mostram que outras equipes dependiam do contrato

Uma API que outras equipes consomem precisa de versão e de documentação, e os dois são sinais de que você tratou o contrato como produto. Cite a versão da rota, como /v1 ou /v2, e a estratégia de mudança, como manter a versão antiga até o consumo migrar. Cite o OpenAPI quando ele existia e era usado para gerar a documentação ou validar requisições.

Antes: Documentação de API.

Depois: Mantive a documentação da API em OpenAPI, publicada junto do código, e criei a rota v2 para mudar o formato da resposta sem quebrar os dois aplicativos que usavam a v1 até a migração.

Documentação escrita depois do código e nunca atualizada não é item para o currículo. Se você a atualizou, diga quando. Se só a copiou de um modelo, não a cite.

Integração com API de terceiros se descreve pelo que você garantiu quando ela falhava

Integrar com um sistema que você não controla significa lidar com lentidão, erro e limite de requisições. São essas partes que a vaga pergunta, porque são elas que quebram em produção. Descreva o que você fez para o seu sistema continuar de pé quando o outro lado falhava:

• Tempo limite e nova tentativa. Defina quanto esperar por uma resposta e quantas vezes tentar de novo, com intervalo crescente, para não sobrecarregar o serviço de terceiro.
• Chave de idempotência. Garante que uma cobrança ou um pedido não seja criado duas vezes quando a resposta se perde no caminho. Cite se você implementou.
• Fila de reprocessamento. Guarda as chamadas que falharam para tentar depois, em vez de perder a operação. Cite que tipo de operação passava por ela.

Antes: Integração com API de pagamento.

Depois: Integrei a API de cobrança do parceiro com tempo limite de dez segundos, nova tentativa com intervalo crescente e chave de idempotência em cada cobrança, o que eliminou as cobranças duplicadas registradas depois de quedas do parceiro.

Testes de API que cobrem o erro são a prova que o recrutador pode conferir

Escreva os testes da API pelo que cobriam: requisição sem autenticação recusada, entrada inválida rejeitada, resposta de erro no formato combinado. Cite a ferramenta usada, como Jest, pytest ou JUnit, conforme a stack. Um teste que cobre só o caminho feliz, escrito como tarefa, não vale como item. Se você quer ver como essa linha aparece num perfil de qualidade, o guia de currículo de analista de QA mostra o caminho.

Sem API construída, o caminho é um projeto com contrato publicado

Quem nunca publicou uma API pode montar uma pequena: três ou quatro rotas para um recurso simples, autenticação por chave ou JWT, testes para as respostas de erro e uma documentação OpenAPI gerada a partir do código. Coloque a API num lugar acessível, mesmo que seja um serviço de nuvem barato, e escreva o que ela faz e quem a consome, ainda que o consumidor seja um aplicativo seu. Esse projeto é honesto e responde às perguntas que a vaga faz. Se ele roda num contêiner, o guia de Docker e Kubernetes no currículo mostra como descrever a execução.

O que fazer agora com o seu currículo

Releia cada linha que cita API REST e pergunte três coisas: a API foi construída ou integrada, qual era o esquema de acesso e quem fazia as chamadas. Se a linha não responde a uma delas, reescreva. Não é preciso escrever tudo. Uma linha bem escrita por experiência vale mais do que cinco termos soltos.

Sem essas respostas, a linha fica como a palavra REST sozinha, que a vaga encontra e a entrevista não sustenta. Para conferir os termos da vaga contra o seu texto, cole a descrição da vaga na análise ATS gratuita. Ela não pede cadastro e mostra quais termos da vaga já estão no seu currículo e quais faltam. Se a vaga for de desenvolvimento completo, veja também as palavras-chave para desenvolvedor full stack.

Perguntas frequentes