Identificadores são fundamentais em uma API RESTful.
Eles determinam como recursos são acessados, relacionados e expostos externamente.
A escolha entre IDs numéricos e UUIDs impacta segurança, escalabilidade, privacidade e integração entre sistemas.
Vamos entender como aplicar cada padrão da forma correta.
O papel dos identificadores
Exemplos comuns:
GET /users/10
GET /orders/99
GET /products/42
Um identificador ideal deve ser:
- único
- imutável
- estável
- consistente
IDs sequenciais: simples, mas limitados
IDs como 1, 2, 3 são simples e eficientes, porém:
❌ expõem o tamanho da base
❌ são previsíveis (facilitam enumeration attack)
❌ exigem coordenação em sistemas distribuídos
❌ revelam ordem e ritmo de criação de registros
Servem bem para sistemas internos, pequenos ou isolados.
Já para APIs públicas, externas ou distribuídas: não são ideais.
UUIDs: identificadores globais únicos
Um UUID v4 típico:
550e8400-e29b-41d4-a716-446655440000
Vantagens:
- difíceis de adivinhar
- não expõem contagem ou ordem
- bons para microsserviços
- excelente unicidade sem coordenação
- ideais para APIs públicas ou expostas a terceiros
UUID não substitui a Primary Key
Mesmo usando UUID em APIs, sua tabela deve continuar tendo:
-
uma chave primária interna, geralmente numérica (
bigint) - um campo UUID separado, usado para exposição externa
Analogia com produtos:
- ID interno (PK) → para o banco
- EAN / SKU / UPC → para sistemas externos
Isso mantém performance interna + segurança externa.
Segurança: UUID ajuda, mas controle de acesso é obrigatório
UUID reduz adivinhação e enumeration, mas não impede acesso indevido.
A API precisa validar:
- tokens (JWT, OAuth2, API Keys)
- escopos e permissões
- se o recurso pertence ao usuário
- prevenção de IDOR (Insecure Direct Object Reference)
Sem isso, mesmo com UUID, um atacante pode tentar:
GET /orders/550e8400-e29b-41d4-a716-446655440000
e acessar dados de terceiros caso não haja validação de propriedade.
Como armazenar UUID de forma eficiente
A recomendação é considerar:
1️⃣ BINARY(16)
Mais compacto e eficiente para índice e armazenamento.
2️⃣ CHAR(36) ou VARCHAR(36)
Usando o formato textual completo do UUID.
Mais simples para debugging e leitura humana.
3️⃣ Alternativas modernas
Para quem precisa de unicidade + ordenação temporal, avalie:
- UUIDv7 (tendência forte — combina timestamp + aleatoriedade)
- ULID (lexicograficamente ordenado, ótimo para bancos NoSQL ou logs)
Esses formatos são ótimos para sistemas distribuídos que exigem ordenação natural nos registros, como eventos, logs, auditorias e tabelas grandes.
Recomendações práticas
Use o padrão:
- PK numérica interna (bigint) → performance e relacionamentos
- UUID v4/v7/ULID externo → segurança e interoperabilidade
Essa abordagem traz o melhor dos dois mundos.
Quando usar UUIDs?
São mais adequados para:
✔ APIs públicas ou acessadas por terceiros
✔ sistemas distribuídos ou com microsserviços
✔ ambientes multi-tenant
✔ aplicações que precisam evitar exposição de dados
✔ recursos criados por múltiplas fontes simultaneamente
Para APIs internas simples, IDs numéricos podem ser mais eficientes.
Para APIs externas, complexas ou distribuídas, UUID é o padrão recomendado.
Resumo
- IDs sequenciais são simples, mas inseguros para APIs públicas
- UUIDs são ótimos como identificadores externos
- Use PK numérica interna + UUID externo
- Formatos recomendados: BINARY(16), CHAR(36), UUIDv7, ULID
- UUID não substitui autenticação, autorização e validação de acesso
- O uso de UUID é mais indicado para cenários complexos, distribuídos e externos
Top comments (0)