Django - Progettazione di URL e best practice per identificare un oggetto

Question

In realtà sto lavorando a un progetto di Django e non sono sicuro del miglior formato dell'URL per accedere a una particolare pagina di oggetto.

stavo pensando a queste alternative:

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

Questo è il modo più semplice e ben noto di farlo. "id_object" è l'ID autoincrementale generato dal motore del database durante il salvataggio dell'oggetto. Il problema che trovo in questo modo è che gli URL sono semplici e iterabili. Quindi possiamo creare uno script semplice e visitare tutte le pagine incrementando l'ID nell'URL. Forse un problema di sicurezza.

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

Il "hash_id" dovrebbe essere un valore stringa alfanumerica, generato ad esempio con funzioni UUID. È una buona idea perché non è iterabile. Ma generare ID univoci "casuali" può causare alcuni problemi.

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

Django è dotato di un campo "slug" per i modelli, e può essere utilizzato per identificare un oggetto nell'URL. Il problema che ho riscontrato in questo caso è che lo slug potrebbe cambiare nel tempo, generando URL danneggiati. Se alcuni motori di ricerca come Google avevano indicizzato questo URL danneggiato, gli utenti potrebbero essere guidati a pagine "non trovate" e il nostro ranking potrebbe diminuire. Il congelamento dello Slug può essere una soluzione. Voglio dire, salva lo slug solo sull'azione "Aggiungi", e non su quella "Aggiorna". Ma la lumaca ora può rappresentare qualcosa di vecchio o sbagliato.

Tutte le opzioni hanno vantaggi e svantaggi. Può essere l'uso di una combinazione di loro può alcuni dei problemi. Cosa ne pensi?

Answer 1

Penso che la soluzione migliore è questa:

.com/object/AUTOINCREMENT_ID/SLUG_FIELD 

Perché?

Primo motivo: l'AUTOINCREMENT_ID è semplice per gli utenti di identificare un oggetto. Ad esempio, in un sito di e-commerce, se l'utente desidera visitare più volte la pagina (perché non è sicuro di acquistare il prodotto) riconoscerà l'URL.

Secondo motivo: Il campo di lumaca impedirà il problema di qualcuno che itera sulla pagina Web e renderà l'URL più chiaro per le persone.

Questo .com/object/10/ford-munstang-2010 è più chiaro che .com/object/c30204225d8311e185c3002219f52617

Answer 2

ID non sono rigorosamente "iterabile". Le cose vengono eliminate, aggiunte di nuovo, ecc. Nel corso del tempo, raramente si verifica una progressione lineare degli ID lineare da 1-1000. Dal punto di vista della sicurezza, non ha molta importanza. Se le visualizzazioni devono essere protette per qualche motivo, si utilizzano gli accessi e si mostra solo ciò che ciascun utente è autorizzato a vedere per ciascun utente.

Ci sono aspetti positivi e negativi in ​​ogni approccio, ma trovo che le lumache siano l'opzione migliore nel complesso. Sono descrittivi, aiutano gli utenti a sapere dove e a colpo d'occhio consentono loro di dire dove stanno andando quando fanno clic su un URL. E, i lati negativi (404 se le lumache cambiano) possono essere mitigati da 1) non cambiare le lumache, mai 2) impostare i reindirizzamenti appropriati quando uno slug deve cambiare per qualche motivo. Django ha persino un framework di reindirizzamenti per renderlo ancora più semplice.

L'idea di combinare un id e una lumaca è semplicemente pazza da dove sono seduto. Continuerai a fare affidamento sull'id o della parte di slug dell'URL, quindi non è intrinsecamente diverso che l'uso esclusivo di uno o dell'altro. Oppure, ci si affida a entrambi e si combinano i problemi e si introducono ulteriori punti di errore. L'utilizzo di entrambi non fornisce alcun vantaggio significativo e non sembra altro che un ottimo modo per introdurre mal di testa.