Efter at have brugt ObjectId s i RESTful API'er flere gange, er den største ulempe egentlig, at de er meget støjende i forhold til at have en ren URL. Du vil enten lade det være et HEX-tal eller konvertere det til et meget stort heltal, hvilket begge giver en noget uvenlig URL:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Jeg har tilføjet en "titel" til URL'en (som StackOverflow gør) for at gøre dem lidt mere venlige:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Selvfølgelig ignoreres "titlen" i software, men brugeren ser den og kan mentalt ignorere det skøre ID-segment.
Der er meget lidt nyttigt, man kunne lære af infrastrukturen ved at afsløre dem:
- Tidsstempel
- Maskin-id
- Proces-id
- Vældig stigende værdi
Andet end potentielt indsamling af maskin-id'er (som generelt ville angive antallet af klienter, der opretter ObjectId s), der er ikke meget der.
ObjectId s er ikke tilfældige, så du kunne ikke bruge dem af sikkerhedsmæssige årsager. Du skal altid sikre dataene. Selvom de måske ikke stiger på en indlysende måde, ville det være nemt at finde andre ressourcer gennem brute force. Men hvis du tidligere brugte auto-incrementing ID'er, er dette ikke et nyt problem for dig.
Hvis du ved, at du ikke opretter mange nye dokumenter på et givet tidspunkt, kan det være værd at bruge et af mønstrene her til at oprette et enklere ID. I en app, jeg skrev, brugte jeg en auto-inc-teknik til nogle af de dokument-id'er, der blev vist i URL'er, og for dem, der kun var Ajax-kun, brugte jeg ObjectId s. Jeg ville virkelig gerne have, at nogle URL'er nemt kunne "skrives". Ingen form for ObjectId er let indtastet af en slutbruger. Det er en af styrkerne ved MongoDB -- at du kan bruge enhver _id format du ønsker. :)