Os IDs de back-end devem ser públicos ou não em uma API REST?

Com base no que esse cara diz: http://toddfredrich.com/ids-in-rest-api.html

Vamos supor que ele esteja certo ao usar o UUID para identificar os recursos da API. Então eu me deparo com problemas tentando implementá-lo dessa maneira, isto é:

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

(Entre cliente e servidor, são enviados e recebidos DTOs, não entidades de banco de dados.)

O problema agora é que idnão é útil, pois não estou mais usando. O cliente faz as solicitações, uidentão por que eu me preocupo em lidar com 2 IDs? Então voltamos à mesma questão do começo. Se eu definir UUID como a chave primária ( _id), exponha o ID do back-end ao público.

Além disso, há o tópico sobre eficiência. Eu li que a indexação por ObjectId é muito mais eficiente que o UUID.

Estou expondo o ID de back-end ao público

Quais outros meios você tem para identificar suas entidades quando elas são retornadas por meio de uma solicitação? Isso é perfeitamente legítimo e mais seguro que o SSN ou identificadores semelhantes. É disso que Todd está falando - tornando a tecnologia de identificação e a entidade neutras e ele está certo.

Tópico de eficiência

Você pode manter os dois identificadores se o ObjectId for realmente muito mais eficiente. Teoricamente, é sempre melhor usar UUIDs para identificadores do que incrementadores automáticos de banco de dados.

Não, no que diz respeito ao banco de dados, nada sobre a estrutura interna é exposto à API externa. Os IDs não têm inteligência. Eles nem são únicos no mundo real. ID: 47 está em todo lugar. Existem entidades às quais você tem acesso e possivelmente podem manipular os dados, mas, se esse banco de dados armazena tudo em uma ou dez tabelas, usa ID incremental como PK e se relaciona a um FK, você nunca saberá.

Se você pode GetUserAccountByID (12345), está apenas pedindo para alguém tentar GetUserAccountByID (12346). Mesmo que não funcione devido a outras medidas de segurança, nem tente e não tente invadir socialmente a empresa solicitando informações na Conta: 12346. A menos que você ligue para o DBA e esteja disposto a esperar duas semanas por um resposta;)

Portanto, crie os GUIDs da maneira que achar melhor ou qualquer outra chave natural, como um número de telefone ou endereço de email. Coloque uma restrição exclusiva no campo da tabela para evitar alguma tentativa obscura de copiar e colar em alguma tentativa de mesclagem de dados.

Isso não é redundante. Os dois campos servem a propósitos diferentes.

Sobre o ID de eficiência versus UUID, a menos que você tenha várias associações envolvendo várias tabelas, cada uma com milhões de registros, isso não fará muita diferença. O uso do UUID torna sua aplicação muito mais difícil de descartar se você não verificar / aplicar diretamente no servidor:

• GET / 1
• GET / 2

É muito fácil usar ID, se você usar UUID, é uma opção a menos para um raspador.

O ID pode ser visto como algo interno à instância de banco de dados do aplicativo. Há três palavras importantes nessa frase:

• Aplicativo: como é o seu modelo, é provável que suas tabelas sejam usadas apenas por esse aplicativo
• Banco de dados: se vários aplicativos o utilizaram no mesmo banco de dados, você estará bem
• Instância (do banco de dados): se você tiver um sistema distribuído, o id entrará em conflito um com o outro e eles não terão sentido para qualquer outro sistema / aplicativo que não use a instância do banco de dados. UUID é a solução para esse caso específico.

De preferência pessoal: prefiro ter um ID simples e um ID comercial exclusivo (email, login, ...). Portanto, se eu tiver que trocar dados, usarei o ID da empresa, porque o sistema de destino pode não manipular o UUID, mas ele provavelmente (nunca diga nunca ...) manipulará uma chave comercial exclusiva.