Tendo usado
ObjectId s em APIs RESTful várias vezes, a maior desvantagem é realmente que elas são muito barulhentas em termos de ter uma URL limpa. Você o deixará como um número HEX ou o converterá em um número inteiro muito grande, ambos criando um URL um tanto hostil:/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Eu adicionei um "título" ao URL (como o StackOverflow faz) para torná-los um pouco mais amigáveis:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Claro, o "título" é ignorado no software, mas o usuário o vê e pode ignorar mentalmente o segmento de ID maluco.
Há muito pouco útil que pode ser aprendido com a infraestrutura, expondo-os:
- Carimbo de data e hora
- ID da máquina
- ID do processo
- Valor de incremento aleatório
Além de coletar potencialmente IDs de máquina (o que geralmente indicaria o número de clientes criando
ObjectId s), não há muito lá. ObjectId s não são aleatórios, então você não pode usá-los para segurança. Você sempre precisará proteger os dados. Embora eles possam não aumentar de maneira óbvia, seria fácil encontrar outros recursos por meio da força bruta. No entanto, se você estava usando IDs de incremento automático antes, esse não é um problema novo para você. Se você sabe que não está criando muitos documentos novos em um determinado momento, pode valer a pena usar um dos padrões aqui para criar um ID mais simples. Em um aplicativo que escrevi, usei uma técnica de auto-inc para alguns dos IDs de documentos mostrados em URLs e, para aqueles que eram somente Ajax, usei
ObjectId s. Eu realmente queria que alguns URLs fossem facilmente "digitados". Nenhuma forma de um ObjectId é facilmente digitado por um usuário final. Esse é um dos pontos fortes do MongoDB -- que você pode usar qualquer _id formato que você deseja. :) 
