Analisar o ObjectId de uma solicitação não seria difícil (portanto, não sei por que isso é um problema?). Se o objetivo é fazer URLs tipáveis, então ter um URL mais curto e "amigável" seria valioso.

Você não pode pegar um número de 12 bytes que é garantido exclusivo em uma configuração fragmentada do MongoDB e condensá-lo para menos de 12 bytes e garantir que seja exclusivo (você mencionou em sete caracteres, por exemplo).

Dos documentos , o ObjectId do MongoDB consiste em:

• um carimbo de data/hora de 4 bytes
• um identificador de máquina de 3 bytes
• um ID de processo de 2 bytes
• e um contador de 3 bytes.

Portanto, você precisará sacrificar parte do ObjectId (e, portanto, fragmentar) ou criar um formato alternativo de criação de ID que seja indexado.

Embora você possa fazer o hash do ID potencialmente, novamente, podem surgir conflitos para os quais você deseja codificar (novamente, você não pode reduzir 12 bytes para 4 bytes e garantir a exclusividade). E se houver conflitos possíveis (e haverá se você reduzir o número total de bits disponíveis), você precisará de algum tipo de tabela secundária de qualquer maneira (e precisaria criar um índice para ir do ID gerado ao ObjectId) .

Opções resultantes:

• Remova bits normalmente significativos -- se você fizer isso, não fragmente a coleção
• Desenvolva sua própria solução de ID exclusiva (e, se estiver em um web-farm, pode parecer muito semelhante ao do MongoDB para lidar com a exclusividade)
• use o ObjectId como um número longo e execute um algoritmo encurtado nele (ele precisará ser dividido primeiro em partes menores, pois excede a precisão numérica de 53 bits do JavaScript), tente este algoritmo por exemplo =codificar (acabará com cerca de 17 caracteres)
• use algo mais curto, mas exclusivo como ID para seus documentos
• Mais fácil:basta aceitar que os IDs são longos. :)

(Não está claro por que o navegador precisaria fazer essa conversão - por que ele teria o ObjectID do documento?)