Ci sono motivi per cui dovrei/non dovrei usare ObjectId nelle URL del mio RESTful

Question

Sto usando mongoDB per la prima volta in un servizio RESTful. Precedentemente la colonna id nei miei database SQL era un intero incrementale, quindi i miei endpoint RESTful avrebbero avuto un aspetto simile a /rest/objectType/1. C'è qualche ragione per cui non dovrei usare solo ObjectId di mongoDB nello stesso ruolo, o è più saggio mantenere una colonna ID integer incrementale separata e usarla per gli URL?

Answer 1

Dopo aver utilizzato ObjectId s in API RESTful diverse volte, il più grande svantaggio è in realtà che sono molto rumorosi in termini di avere un URL pulito. Potrete sia lasciarlo come un numero esadecimale, o convertirlo in un grande numero intero, sia rendendo per un po 'ostile URL:

/rest/resource/52435dbecb970072ec3a780f 
/rest/resource/25459211534898951476729247759 

Ho aggiunto un "titolo" per l'URL (come StackOverflow fa) per renderli un po 'più amichevole:

/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName 

Naturalmente, il "titolo" è ignorato nel software, ma l'utente vede e può mentalmente ignorare il segmento ID pazzo.

C'è molto poco utile che potrebbe essere imparato dalle infrastrutture esponendoli:

1. timestamp
2. ID macchina
3. Process ID
4. a caso valore incrementando

Tranne potenzialmente in grado di raccogliere gli ID macchina (che in genere indicano il numero di client che creano ObjectId s), non c'è molto lì.

ObjectId s non sono casuali, quindi non è possibile utilizzarli per sicurezza. Avrai sempre bisogno di proteggere i dati. Sebbene non possano incrementare in modo evidente, sarebbe facile trovare altre risorse attraverso la forza bruta. Tuttavia, se in precedenza si utilizzavano ID di incremento automatico, questo non rappresenta un nuovo problema.

Se si sa che non si stanno creando molti nuovi documenti in un dato momento, potrebbe valere la pena di utilizzare uno dei modelli here per creare un ID più semplice. In una app che ho scritto, ho usato una tecnica di auto-inc per alcuni degli ID dei documenti mostrati negli URL, e per quelli che erano solo Ajax, ho usato ObjectId s. Volevo davvero che alcuni URL venissero facilmente "digitati". Nessuna forma di ObjectId è facilmente digitata da un utente finale. Questo è uno dei punti di forza di MongoDB: puoi utilizzare qualsiasi formato _id che desideri. :)

Answer 2

È più saggio utilizzare ObjectId s, perché mantenere un contatore incrementale può essere un collo di bottiglia. Inoltre, poiché ObjectId contiene un timestamp ed è monotono, possono essere utili per ottimizzare le query.

ObjectIds Il ObjectIds può essere indovinato, ma poiché ciò è sicuramente vero per l'incremento degli ID, sospetto che non abbiate fatto affidamento sulla sicurezza attraverso l'oscurità prima, quindi non è un problema per voi.

Uno svantaggio, anche se di dimensioni ridotte, è che il tempo di creazione sul server passa all'utente, ovvero se l'utente è in grado di identificarlo come ObjectId, può decodificare il tempo di creazione dell'oggetto. Questo è l'unico potenziale problema che vedo.