Habiendo usado ObjectId s en las API RESTful varias veces, la mayor desventaja es que son muy ruidosas en términos de tener una URL limpia. Lo dejarás como un número hexadecimal o lo convertirás en un número entero muy grande, lo que generará una URL poco amigable:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Agregué un "título" a la URL (como lo hace StackOverflow) para que sea un poco más amigable:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Por supuesto, el "título" se ignora en el software, pero el usuario lo ve y puede ignorar mentalmente el loco segmento de ID.
Hay muy poco que se pueda aprender de la infraestructura exponiéndolos:
- Marca de tiempo
- ID de máquina
- Identificación del proceso
- Valor incremental aleatorio
Aparte de la posible recopilación de ID de máquina (que generalmente indicaría la cantidad de clientes que crean ObjectId s), no hay mucho allí.
ObjectId Los correos electrónicos no son aleatorios, por lo que no podría usarlos por seguridad. Siempre tendrá que proteger los datos. Si bien es posible que no se incrementen de manera obvia, sería fácil encontrar otros recursos a través de la fuerza bruta. Sin embargo, si antes usaba ID de incremento automático, este no es un problema nuevo para usted.
Si sabe que no está creando muchos documentos nuevos en un momento dado, podría valer la pena usar uno de los patrones aquí para crear una identificación más simple. En una aplicación que escribí, usé una técnica de aumento automático para algunos de los ID de documentos que se mostraban en las URL, y para aquellos que eran solo Ajax, usé ObjectId s. Realmente quería que algunas URL se "escribieran" fácilmente. Sin forma de ObjectId es fácil de escribir por un usuario final. Esa es una de las fortalezas de MongoDB, que puede usar cualquier _id formato que desee. :)
