Django - Thiết kế URL và thực tiễn tốt nhất để xác định một đối tượng

Question

Im thực sự làm việc trong dự án django và tôi không chắc chắn về định dạng tốt nhất của URL để truy cập vào một trang đối tượng cụ thể.

Tôi đã suy nghĩ về những lựa chọn thay thế:

1) Using the autoincremental ID => .com/object/15 

Đây là cách đơn giản nhất và nổi tiếng của làm điều đó. "id_object" là ID tự động được tạo bởi công cụ cơ sở dữ liệu trong khi lưu đối tượng. Vấn đề tôi tìm thấy theo cách này là các URL có thể lặp lại đơn giản. Vì vậy, chúng tôi có thể tạo một tập lệnh đơn giản và truy cập tất cả các trang bằng cách tăng ID trong URL. Có thể là một vấn đề an ninh.

2) Using a <hash_id> => .com/object/c30204225d8311e185c3002219f52617 

"hash_id" phải là một số giá trị chuỗi chữ và số, được tạo ví dụ với hàm uuid. Đó là một ý tưởng hay vì nó không thể lặp lại được. Nhưng tạo ID đơn "ngẫu nhiên" có thể gây ra một số vấn đề.

3) Using a Slug => .com/object/some-slug-generated-with-the-object 

Django có trường "slug" cho mô hình và có thể dùng để xác định đối tượng trong URL. Vấn đề tôi tìm thấy trong trường hợp này là slug có thể thay đổi trong thời gian, tạo ra các URL bị hỏng. Nếu một số công cụ tìm kiếm như Google đã lập chỉ mục URL bị hỏng này, người dùng có thể được hướng dẫn đến các trang "không tìm thấy" và thứ hạng trang của chúng tôi có thể giảm. Freezing the Slug có thể là một giải pháp. Ý tôi là, chỉ lưu con sên vào hành động "Thêm" chứ không phải trong bản "Cập nhật". Nhưng slug bây giờ có thể đại diện cho một cái gì đó cũ hoặc không chính xác.

Tất cả các tùy chọn đều có ưu điểm và nhược điểm. Có thể sử dụng một số kết hợp của họ có thể một số vấn đề. Bạn nghĩ sao về điều đó?

Answer 1

Tôi nghĩ rằng lựa chọn tốt nhất là thế này:

.com/object/AUTOINCREMENT_ID/SLUG_FIELD 

Tại sao?

Lý do đầu tiên: AUTOINCREMENT_ID rất đơn giản để người dùng xác định đối tượng. Ví dụ: trong trang web thương mại điện tử, Nếu người dùng muốn truy cập nhiều lần trang (vì anh ấy không chắc chắn mua sản phẩm), anh ấy sẽ nhận ra URL.

Lý do thứ hai: Trường slug sẽ ngăn sự cố của ai đó lặp lại trên trang web và làm cho URL rõ ràng hơn với mọi người.

.com/object/10/ford-munstang-2010 Đây là rõ ràng hơn so với .com/object/c30204225d8311e185c3002219f52617

Answer 2

ID là không đúng "iterable". Những thứ bị xóa, thêm lại, v.v. Theo thời gian, rất hiếm khi có sự tiến triển tuyến tính thẳng của ID từ 1-1000. Từ góc độ bảo mật, nó không thực sự quan trọng. Nếu các chế độ xem cần được bảo vệ vì một số lý do, bạn sử dụng thông tin đăng nhập và chỉ hiển thị những gì mỗi người dùng được phép xem cho từng người dùng.

Có những thay đổi và nhược điểm với mọi cách tiếp cận, nhưng tôi thấy sên là lựa chọn tốt nhất. Chúng mang tính mô tả, chúng giúp người dùng biết vị trí tại đó và trong nháy mắt cho phép họ biết nơi họ sẽ đến khi họ nhấp vào một URL. Và, những nhược điểm (404s nếu sên thay đổi) có thể được giảm nhẹ bởi 1) không thay đổi slugs, bao giờ 2) thiết lập chuyển hướng thích hợp khi một slug không cần phải thay đổi vì một lý do nào đó. Django thậm chí còn có một khung chuyển hướng được tạo sẵn để làm cho điều đó dễ dàng hơn.

Ý tưởng kết hợp id và một con ốc sên chỉ phát điên từ nơi tôi đang ngồi. Bạn vẫn dựa vào id hoặc phần sên của URL, do đó, nó vốn không khác gì bằng cách sử dụng một hoặc độc quyền khác. Hoặc, bạn dựa vào cả hai và kết hợp các vấn đề của bạn và giới thiệu thêm các điểm thất bại. Sử dụng cả hai chỉ đơn giản là cung cấp không có lợi ích có ý nghĩa và có vẻ như không có gì hơn là một cách tuyệt vời để giới thiệu đau đầu.