Tôi có nên sử dụng UUID cho các tài nguyên trong API công khai của mình không?

Tôi đang xây dựng một ứng dụng SaaS và muốn hiển thị ID cho các tài nguyên không liên quan đến việc triển khai lưu trữ dữ liệu hiện tại của tôi (ID tăng tự động Postgres). Các bài đăng Stack Overflow này ( một hai ) gợi ý rằng việc tạo ID duy nhất cục bộ là khó và tôi cũng có thể sử dụng UUID, tất nhiên được tạo dễ dàng và an toàn bằng khá nhiều ngôn ngữ.

Tôi hài lòng với cách tiếp cận này, nhưng tôi tự hỏi tại sao tôi không thể tìm thấy bất kỳ API nào từ các SaaS lớn / người chơi được lưu trữ làm tương tự? Ví dụ:

• Shopify: số có 9 chữ số
• Twilio: 34 chuỗi ký tự
• Twitter: hơn 20 số chữ số
• AMEE: 12 ký tự A-Z0-9

Vì vậy, về cơ bản dường như không ai sử dụng UUID. Có lý do cho điều này - thuật toán ID nội bộ thông minh hơn không - không được phát minh ra ở đây hay thứ gì khác? Và trong trường hợp của tôi, trong trường hợp không có bất kỳ thuật toán nội bộ nào, việc sử dụng UUID có hợp lý nhất không?

Có thể những nhà cung cấp khác mà bạn đã liệt kê có ID hoặc lược đồ băm của riêng họ để cho phép họ hiển thị số lượng nhỏ hơn trong khi sử dụng thứ gì đó giống với UUID hơn trong nội bộ. Nhưng cuối cùng, câu hỏi phải được đặt ra: miễn là URI của bạn được sử dụng bởi mã (ứng dụng khách API) chứ không phải con người, tại sao điều đó lại quan trọng?

Đừng quá lo lắng về những gì các nhà cung cấp đó đã làm. Không có gì đảm bảo rằng (a) họ đang làm điều "đúng đắn" và (b) rằng nhu cầu của họ cũng giống như nhu cầu của bạn.

Hãy tiếp tục và sử dụng UUID.

Tôi nghĩ bạn có thể cân nhắc bốn lựa chọn chính ở đây:

1. sử dụng UUID làm Khóa chính trong cơ sở dữ liệu của bạn, nhưng nó có thể tốn kém về mặt tính toán hơn so với sử dụng Long

2. tạo một lớp ánh xạ UUID to Long, theo cách này, bạn có thể xuất bản tài nguyên REST của mình nhưng vẫn duy trì cấu trúc cơ sở dữ liệu sạch bằng Long PK

3. tạo cột Khóa thay thế trong các bảng cơ sở dữ liệu của bạn để giữ các giá trị UUID.

4. thay vì sử dụng UUID, bạn có thể có ID mật mã, được tạo nhanh chóng bằng cách sử dụng hạt giống tùy chỉnh cho từng khách hàng và PK gốc. Cách tiếp cận này yêu cầu nhiều chi phí thực thi hơn nhưng có thể thú vị trong một số trường hợp. Khách hàng sẽ phải luôn sử dụng dữ liệu được mã hóa, vì họ sẽ không bao giờ có quyền truy cập vào hạt giống hoặc thuật toán.