Nên để Unique Identifier nào trên cái Route?

Yo fen,

Hôm nay ta sẽ qua bài khá là cơ bản và thú vị nhé, đó chính là Unique Identifier (ID) để trên cái route, và từ đó bạn sẽ biết dc users đang access resource nào.

Ví dụ: article/1 => access vào Article có ID là 1 (really traditional way)

Let’s go

ID – article/1

Vâng, rất là basic và traditional way, tạo id xong xài luôn id trên URL.

Lợi thế:

• Nhanh gọn lẹ & ngắn gọn
• Bản thân id là một primary key => index => search nhanh là điều chắc chắn
• URL cực kỳ thân thiện và dễ nhớ

Nhưng:

• Users có thể hijack cái id (đổi qua 2, 3, 100,…) để access
  • Đối với các system quan trọng, cần phải check kỹ permission xem user có dc access hay ko
• Cảm thấy như DB của bạn bị lộ 1 dữ liệu khá là quan trọng – ở đây là raw ID.
• Nếu là public website => SEO ko tốt và ko thân thiện với user
• Security ko dc cao

Slug – products/iphone-13-pro-max

Cái này là 1 cái thông dụng thứ 2, nhất là các public websites rất chuộng, lợi thế là:

• SEO tốt, thân thiện với ng` dùng
  • Đứng ở khía cạnh end-user, bạn nhìn URL là bạn sẽ biết 1 phần details của cái link đó là gì
  • Sẽ dc điểm cao từ Search Engine và khả năng match keyword cũng cao lên.
• Không dễ dàng để hijack
  • Sure kèo thì bạn vẫn phải check permission đối với các webapp quan trọng.

Bất lợi/cần chú ý:

• Đánh unique index cho column slug , và chỉ search exact only (slug = '...')
• Phải tự generate slug trước khi insert
  • Ngoài ra creator cũng có thể tự tạo slug cho riêng mình
• Phải luôn luôn check sự tồn tại (existance) trước khi insert/update

UUID – accounts/1a444d1c-2a0a-4056-911a-e60d5684905e

Cái này cũng khá phổ biến và ngon lành, lợi thế:

• Không dễ dàng để hijack
  • Sure kèo thì bạn vẫn phải check permission đối với các webapp quan trọng.
• Ko cần phải check unique khi insert vì gần như là UUID sẽ ko bị duplicated
  • Luôn luôn kèm UUID mỗi khi insert nhóe.

Bất lợi/cần chú ý:

• SEO ko tốt tương tự như traditional ID
• Ko thân thiện với users
• Tương tự như slug, đánh unique index cho column uuid, và chỉ search exact only (uuid = '...')

Cái này thường được sử dụng bởi các SaaS, internal systems/products,… Và đa phần các systems đó ko cần SEO, nên ko quan trọng vụ này.

Public website mà muốn xài UUID thì nên suy nghĩ kỹ.

Encrypt ID – documents/{encryptedID}

Cái này là từ những projects sáng tạo, họ encrypt lại ID rồi return về, sẽ có link như là: documents/adsfhadskjgfhjkewghj3k2g4k3j2g5rjlk34bgrlkjh (blah blah blah)

Cụ thể là sẽ sử dụng các algo mà có thể encode và decode dc (tất nhiên ko xài Base64 vì dễ đoán quá), ví dụ như AES 256.

Thì cái này chắc mình nghĩ chỉ có 1 lợi thế duy nhất là ko cho User biết dc ID để mà hijack.

Còn bất lợi:

• Phải luôn encrypt khi trả về client
• Phải luôn decrypt khi nhận request từ client.
  • Cái encrypt/decrypt này tốn kha khá time đấy, nhất là khi return 1 list data chẳng hạn, fải traverse hết list và encrypt => bad performance.
• Kiểu gì cũng phải check permissions sau khi decrypt, get by id.
• URL vừa dài vừa xấu, cực kỳ ko thân thiện
  • Mình còn nghĩ nó có thể take space khi users bookmark lại 1 vài link, mà link thì dài vãi.

Finally – in my opinion

Đây là cách mình đang follow cho các projects của mình (từ cá nhân cho tới product của cty):

• Traditional ID – dành cho những pages mà ADMIN only, vì đã là admin hệ thống chả ai hijack làm chi, full permissions rồi.
• UUID – dành cho private pages (cần login để sử dụng nên ko cần SEO)
• Slug – dành cho public websites (như blog mình chẳng hạn – SEO tốt hơn)

(No way cho cái cuối nhé 🤣)

Thanks guys! See you in the next sharing topic!