Po użyciu ObjectId s w RESTful API kilka razy, największą wadą jest to, że są one bardzo hałaśliwe, jeśli chodzi o posiadanie czystego adresu URL. Zostawisz go jako liczbę HEX lub przekonwertujesz na bardzo dużą liczbę całkowitą, co spowoduje nieco nieprzyjazny adres URL:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Dodałem „tytuł” do adresu URL (tak jak robi to StackOverflow), aby uczynić go nieco bardziej przyjaznym:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Oczywiście „tytuł” jest ignorowany w oprogramowaniu, ale użytkownik go widzi i może mentalnie zignorować szalony segment ID.
Z infrastruktury można się nauczyć bardzo niewiele, wystawiając je:
- sygnatura czasowa
- Identyfikator maszyny
- Identyfikator procesu
- Losowo rosnąca wartość
Inne niż potencjalne zbieranie identyfikatorów komputerów (które ogólnie wskazują liczbę klientów tworzących ObjectId s), nie ma tam zbyt wiele.
ObjectId s nie są losowe, więc nie można ich użyć dla bezpieczeństwa. Zawsze będziesz musiał zabezpieczyć dane. Chociaż mogą nie zwiększać się w oczywisty sposób, łatwo byłoby znaleźć inne zasoby za pomocą brutalnej siły. Jeśli jednak używałeś wcześniej identyfikatorów z automatyczną inkrementacją, nie jest to dla Ciebie nowy problem.
Jeśli wiesz, że w danym momencie nie tworzysz wielu nowych dokumentów, warto użyć jednego z dostępnych tutaj wzorców, aby utworzyć prostszy identyfikator. W jednej z aplikacji, które napisałem, użyłem techniki auto-inc dla niektórych identyfikatorów dokumentów, które były wyświetlane w adresach URL, a dla tych, które były tylko Ajax, użyłem ObjectId s. Naprawdę chciałem, aby niektóre adresy URL można było łatwo „wpisać”. Brak formy ObjectId jest łatwo wpisywany przez użytkownika końcowego. To jedna z mocnych stron MongoDB — możesz użyć dowolnego _id żądany format. :)
