Đã sử dụng ObjectId trong các API RESTful nhiều lần, nhược điểm lớn nhất là chúng rất ồn ào về mặt có một URL sạch. Bạn sẽ để nó dưới dạng số HEX hoặc chuyển đổi nó thành một số nguyên rất lớn, cả hai đều tạo ra một URL hơi không thân thiện:
/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759
Tôi đã thêm "tiêu đề" vào URL (giống như StackOverflow) để làm cho chúng thân thiện hơn một chút:
/rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName
Tất nhiên, "tiêu đề" bị bỏ qua trong phần mềm, nhưng người dùng nhìn thấy nó và có thể bỏ qua phân đoạn ID điên rồ.
Có rất ít điều hữu ích có thể học được từ cơ sở hạ tầng bằng cách làm lộ chúng:
- Dấu thời gian
- ID máy
- ID quy trình
- Giá trị gia tăng ngẫu nhiên
Ngoài khả năng thu thập ID máy (thường chỉ ra số lượng khách hàng tạo ObjectId s), không có nhiều thứ ở đó.
ObjectId s không phải là ngẫu nhiên, vì vậy bạn không thể sử dụng chúng để bảo mật. Bạn sẽ luôn cần bảo mật dữ liệu. Mặc dù chúng có thể không tăng lên một cách rõ ràng, nhưng sẽ rất dễ dàng để tìm thấy các nguồn lực khác thông qua thói vũ phu. Tuy nhiên, nếu bạn đã sử dụng ID tự động tăng trước đây, thì đây không phải là vấn đề mới đối với bạn.
Nếu bạn biết rằng mình không tạo nhiều tài liệu mới tại bất kỳ thời điểm nào, bạn nên sử dụng một trong các mẫu ở đây để tạo ID đơn giản hơn. Trong một ứng dụng tôi đã viết, tôi đã sử dụng kỹ thuật auto-inc cho một số ID tài liệu được hiển thị trong URL và đối với những ID chỉ dành cho Ajax, tôi đã sử dụng ObjectId S. Tôi thực sự muốn một số URL được "gõ" dễ dàng. Không có dạng ObjectId được người dùng cuối đánh máy một cách dễ dàng. Đó là một trong những điểm mạnh của MongoDB - bạn có thể sử dụng bất kỳ _id nào định dạng bạn muốn. :)
