Versionar uma API sem quebrar cliente
Pergunta
Quais as estratégias de versionamento de API e o que conta como mudança que quebra (breaking change)?
Resposta esperada
Estratégias: versão no caminho (`/v1/...`, `/v2/...`) — visível, simples de rotear, mas duplica superfície; header (`Accept: application/vnd.api.v2+json`) — limpo mas menos óbvio e mais difícil de testar no navegador; parâmetro de query — desencorajado. Quebra o cliente: remover ou renomear um campo/endpoint, mudar o tipo de um campo, tornar opcional um campo que era garantido na resposta, tornar obrigatório um parâmetro que era opcional, mudar o significado/semântica de um valor, mudar códigos de status. Não quebra (evolução aditiva): adicionar campo novo na resposta, adicionar endpoint, adicionar parâmetro opcional. A prática saudável é evoluir de forma aditiva e só criar v2 quando uma quebra é inevitável, mantendo v1 por um período de depreciação anunciado.
Por que perguntam isso
Pergunta pleno/sênior. Sinal forte: listar o que NÃO quebra (evolução aditiva) e defender só versionar quando a quebra é inevitável, com janela de depreciação.