Abbiamo un database di risorse, siano essi prodotti, post di blog o qualcosa del genere. Abbiamo bisogno di progettare uno schema URL per affrontarli, per il sito web pubblico.
Ecco due esempi che sono legati all'ID del database:
Ecco un esempio che è amichevole:
(Un piccolo assaggio nella mia vita di navigazione lì)
Mi piacciono gli URL amichevoli perché hai un'idea di cosa c'è nella parte finale dell'URL quando passi il mouse su una email o un documento. È meglio per il SEO, o lo era di solito.
Cosa succede quando il documento o il prodotto viene rinominato? O perché è cambiato (il Wiki potrebbe non cambiare ma le nostre risorse potrebbero) o a causa di un errore di battitura, giusto? Le nostre risorse sono molto tecniche, lunghe parole e inclini agli errori.
Inoltre, abbiamo un ID del database, che è un numero. Diamo un'occhiata a un'idea per un indirizzo di un video utilizzando un negozio fittizio:
L'ID è ovvio e viene utilizzato nella ricerca DB. Bene.
Il bit delle porte scorrevoli non è univoco e appena generato dal titolo del video, può essere verificato su GET, quindi se sono state inserite porte scorrevoli e non corrisponde a ciò che è realmente presente nel documento 287171, risponde 404.
O forse potrebbe essere ignorato, permettendo agli umani di attaccare qualsiasi cosa a loro piace lì, se qualcuno gliene fosse mai importato. Quindi questo URL funzionerebbe anche:
Il problema con la verifica della parte amichevole è, come accennato, il problema della ridenominazione o della correzione di errore di battitura. Se il nome è cambiato e nel nostro dominio ciò accade, non vogliamo rompere gli URL che sono là fuori, quindi dovremmo:
-
Non verificare la parte amichevole.
-
Verifica, ma aggiungi una "cronologia" di parti amichevoli al record del database in modo che tutti i precedenti ID amiche funzionino ancora!
I tuoi pensieri e le tue idee sono ben accetti.
Luca