Aver utilizzato ObjectId s nelle API RESTful più volte, il più grande svantaggio è davvero che sono molto rumorose in termini di avere un URL pulito. Lo lascerai come numero esadecimale o lo convertirai in un numero intero molto grande, creando entrambi un URL alquanto ostile:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Ho aggiunto un "titolo" all'URL (come fa StackOverflow) per renderli leggermente più amichevoli:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Naturalmente, il "titolo" viene ignorato nel software, ma l'utente lo vede e può ignorare mentalmente il pazzo segmento ID.
C'è ben poco di utile che potrebbe essere appreso dall'infrastruttura esponendole:
- Data e ora
- ID macchina
- ID processo
- Valore incrementale casuale
Oltre alla potenziale raccolta di ID macchina (che in genere indicherebbe il numero di client che creano ObjectId s), non c'è molto.
ObjectId s non sono casuali, quindi non puoi usarli per sicurezza. Avrai sempre bisogno di proteggere i dati. Anche se potrebbero non aumentare in modo ovvio, sarebbe facile trovare altre risorse attraverso la forza bruta. Tuttavia, se in precedenza stavi utilizzando ID a incremento automatico, questo non è un nuovo problema per te.
Se sai che non stai creando molti nuovi documenti in un dato momento, potrebbe valere la pena utilizzare uno dei modelli qui per creare un ID più semplice. In un'app che ho scritto, ho usato una tecnica di auto-inc per alcuni degli ID documento che sono stati mostrati negli URL, e per quelli che erano solo Ajax, ho usato ObjectId S. Volevo davvero che alcuni URL fossero facilmente "digitati". Nessuna forma di ObjectId è facilmente digitato da un utente finale. Questo è uno dei punti di forza di MongoDB:puoi usare qualsiasi _id formato che desideri. :)
