Uso de CPF ao invés de ID

Oi, Bruno! Como vai?

Essa é uma ótima pergunta e é um tema que pode gerar bastante discussão. Utilizar o CPF como identificador na API ao invés de um ID gerado pelo banco de dados tem algumas implicações e possíveis vantagens, dependendo do contexto da aplicação.

1. Unicidade Natural: O CPF é um identificador único para cada pessoa no Brasil, o que garante que não haverá duplicidade de registros baseados nesse campo. Isso pode ser útil em sistemas onde a unicidade do CPF é um requisito importante.

2. Legibilidade e Clareza: Em alguns casos, utilizar um identificador que tem significado no mundo real (como o CPF) pode tornar a API mais clara e fácil de entender por quem está consumindo-a. Isso pode ser especialmente útil em sistemas onde o CPF é um dado frequentemente utilizado.

3. Integração com Outros Sistemas: Se o sistema precisa se integrar com outros sistemas que também usam CPF como identificador, pode ser mais prático e direto usar o CPF em vez de um ID interno.

No entanto, é importante considerar que há desvantagens também. Por exemplo, o CPF é um dado pessoal e sensível, então é preciso ter cuidado redobrado com segurança e privacidade. Além disso, operações de busca e atualização podem ser menos eficientes se o CPF não for indexado adequadamente no banco de dados.

Em resumo, a escolha entre usar CPF ou um ID gerado pelo banco de dados como identificador depende das necessidades específicas do seu projeto e dos requisitos de negócio. Não há uma resposta única, mas espero que essas considerações te ajudem a entender melhor as implicações dessa escolha.

Espero ter esclarecido e bons estudos!

Realmente são vantagens interessantes.

Quanto a essa questão do CPF ser um dado pessoal e sensível, será que esbarra em algo relacionado a LGPD? Visto que com https no corpo da requisição iria escondido, diferentemente da url.

Oi, Bruno!

Sobre sua última dúvida: usar o CPF na URL pode, sim, levantar preocupações em relação à LGPD.

Mesmo com o uso de HTTPS, dados sensíveis na URL ainda são considerados uma má prática por dois motivos principais:

1. Logs e rastros: URLs podem ser armazenadas em logs de servidores, proxies e navegadores. Isso significa que o CPF pode acabar sendo registrado em locais não protegidos.
2. Compartilhamento acidental: quando uma URL contendo o CPF é compartilhada (por e-mail, print, etc.), ela carrega junto um dado pessoal sensível.

O ideal, para estar em conformidade com a LGPD, é usar o ID gerado internamente na URL (por exemplo: /clientes/123), e o CPF ser tratado somente no corpo da requisição, quando realmente necessário.

Veja como ficaria uma abordagem mais segura:

// Exemplo de requisição para buscar cliente por CPF
POST /clientes/buscar
{
  "cpf": "12345678900"
}

Dessa forma:

• Você evita exposição do CPF na URL;
• Garante melhor conformidade com a LGPD;
• E ainda mantém flexibilidade para usar o CPF na lógica de negócio.

Resumindo: evite o CPF na URL sempre que possível, mesmo com HTTPS. Isso reduz riscos legais e técnicos.

Fico à disposição. Abraços e bons estudos!