Fornire URL intuitivi per un sito Web rispetto alle realtà degli ID del database

24

Abbiamo un database di risorse, siano essi prodotti, post di blog o qualcosa del genere. Dobbiamo progettare uno schema URL per indirizzarli, per il sito Web pubblico.

Ecco due esempi associati all'ID database:

Ecco un esempio che è amichevole:

http://en.wikipedia.org/wiki/LED_circuit

(Un piccolo sguardo alla mia vita di navigazione lì)

Mi piacciono gli URL amichevoli poiché hai un'idea di cosa c'è alla fine dell'URL quando passi il mouse o lo vedi in un'e-mail o in un documento. È meglio per SEO, o lo era una volta.

Cosa succede quando il documento o il prodotto viene rinominato? O perché è cambiato (Wiki potrebbe non cambiare ma le nostre risorse potrebbero) o a causa di un errore di battitura, giusto? Le nostre risorse sono molto tecniche, parole lunghe e soggette a errori.

Inoltre, abbiamo un ID database, che è un numero. Diamo un'occhiata a un'idea per un indirizzo di un video usando un negozio di noleggio fasullo:

http://vidsyeah.com/video/sliding-doors/287171

L'ID è ovvio e viene utilizzato nella ricerca DB. Belle.

Il bit per porte scorrevoli non è univoco e appena generato dal titolo del video, potrebbe essere verificato su GET, quindi se si inseriscono le porte scorrevoli e non corrispondono a ciò che è veramente nel documento 287171, risponde 404.

O forse potrebbe essere ignorato, permettendo agli umani di attaccare quello che vogliono lì, se qualcuno lo avesse mai curato. Quindi questo URL funzionerebbe anche:

http://vidsyeah.com/video/anything-at_all/287171

Il problema con la verifica della parte amichevole è, come detto, il problema della ridenominazione o della correzione dell'errore di battitura. Se il nome è cambiato e nel nostro dominio accade, non vogliamo interrompere gli URL disponibili, quindi dovremmo:

Basta non verificare la parte amichevole.
Verifica, ma aggiungi una 'cronologia' delle parti amichevoli al record del database in modo che tutti gli ID amichevoli precedenti funzionino ancora!

I tuoi pensieri e idee sono i benvenuti.

Luca

— Luke Puplett
fonte

11

anche questo stesso sito utilizza una combinazione http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(utilizzando una versione non verificata alla luce delle modifiche del titolo, anche il link "condividi" più breve è solo l'id: http://programmers.stackexchange.com/q/255684/25768(e l'id utente per il tracciamento dei badge)

— maniaco del cricchetto

11

Se hai un ID univoco nel tuo URL, non vedo perché dovresti voler verificare la parte della lumaca. Usalo per i look e ignoralo per le ricerche.

— Thorsten Müller,

Se uno di voi vuole dare una risposta adeguata, voterò in modo da ottenere i punti. Lascerò entrare i voti e assegnerò la risposta ai più votati tra un paio di giorni.

— Luke Puplett,

1

programmers.stackexchange.com/questions/231483/…

— moscerino

3

Non ho mai conosciuto il termine lumaca prima. Devo essere stato sotto una roccia. Geddit?

— Luke Puplett,

6

Mantenere l'ID nell'URL è il metodo più sicuro per il futuro e, come dimostrato, gli URL possono comunque avere un aspetto relativamente buono.

Un'altra opzione utilizzata da più progetti è quella di mantenere una cronologia delle lumache utilizzate in precedenza. Quando il titolo cambia, aggiorni la lumaca e se qualcuno cerca una lumaca obsoleta, cerca nell'elenco delle lumache vecchie. In questo modo le vecchie lumache possono essere riutilizzate per nuovi contenuti (o non dipende dalla tua implementazione).

Wordpress lo ha fatto e così ha fatto la gemma friendly_id che è probabilmente la gemma più utilizzata per la gestione di ID amichevoli per Rails.

Inoltre, mentre mi piacciono gli URL di bell'aspetto, penso che sia importante ricordare che questa è molto probabilmente una funzionalità utilizzata da utenti più esperti di tecnologia. Alcuni browser stanno persino iniziando a nascondere gli URL (o parte di essi).

— mbillard
fonte

2

Questa storia della lumaca è ciò che stavo prendendo in considerazione. Da quando ho pubblicato la domanda, ho notato molti siti di grandi nomi che hanno una lumaca che non è selezionata, puoi cambiarla per dire qualcosa. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 funziona. StackExchange è intelligente poiché "corregge" e reindirizza il browser per garantire che il collegamento corretto sia mostrato e condiviso.

— Luke Puplett,

Una "lumaca" è meno utile per le persone e più utile per l'ottimizzazione dei motori di ricerca, in quanto una "lumaca" o un "URL descrittivo" devono contenere parole chiave relative al contenuto della pagina. Gli utenti esperti non sono la ragione per includere URL amichevoli nel tuo sito. Le classifiche dei motori di ricerca tendono ad essere il motivo principale.

— Greg Burghardt,

Non sono d'accordo. Gli URL con solo ID sono difficili da lavorare; è difficile ricordare da un elenco di quelli a cui potresti voler tornare. O se ci sarà qualcosa di inappropriato all'altra estremità del collegamento. La barra degli indirizzi di Chrome suggerisce anche su qualsiasi parte dell'URL, il che è utile.

— Luke Puplett,

1

@LukePuplett sì, credo che il modo in cui SE gestisce gli URL sia il più semplice quando si tratta di lumache.

— mbillard,

@GregBurghardt l'unica differenza è nella percentuale di clic, gli utenti tendono a fare clic su un po 'più friendly URL: stackoverflow.com/questions/505793/...

— mbillard

3

Ho usato due diversi scenari in passato.

/id/some-slugdove la idviene utilizzato per cercare , la lumaca non è. Quindi la lumaca può essere qualsiasi cosa . Tuttavia, quando la lumaca non corrisponde alla lumaca effettiva, l'utente viene reindirizzato alla versione corrente.
/permalinkper i casi in cui non volevamo un ID nell'URL o dove l'URL non dovesse mai cambiare, anche se è disponibile un ID (vedere [1] e [2] ). Naturalmente, in questo caso il permalinkviene utilizzato per la ricerca . Sia la lumaca corrente che la permalink (la prima lumaca) sono archiviate nel database.

In nessuno di questi modi è necessario mantenere una cronologia delle lumache nel database, che diventerebbe problematica molto presto.

ps: nel secondo caso avrai bisogno di un routing molto specifico per mantenere i crediti sociali:

se lo desideri, reindirizza gli utenti all'URL corrente (non permalink)
utilizza il permalink come url nei pulsanti social
reindirizza sempre il crawler di Facebook al permalink

Vedi di nuovo [1] e [2] .

— filone
fonte

Perché sarà problematico? Se tengo e ID e lumaca sono qualcosa, il visitatore andrà alla pagina reale. Sarà dannoso per la SEO?

— Jnanaranjan,

Intendi mantenere una storia di lumache? Cosa fai quando qualcuno vuole riutilizzare tale lumaca? Per lo stesso o un altro ID? Come si progettano database e / o codice per prevenire reindirizzamenti multipli? Vuoi nascondere l'esistenza dopo la cancellazione e i reindirizzamenti espongono l'esistenza precedente? Tutto ciò non è impossibile, ma solleva tutti i tipi di domande che preferisco semplicemente prevenire in base alla progettazione.

— Lode

Quello che volevo dire è se l'ID è presente nell'URL, qualunque sia la lumaca verrà reindirizzato alla pagina richiesta. Quindi la storia della lumaca non ha importanza. Sono d'accordo che è problematico per Android però.

— Jnanaranjan,

1

Ah ok. Questo è quello che ho aggiunto uno scenario 1 giusto? O intendi qualcos'altro?

— Lode

Sì. È corretto.

— Jnanaranjan il

2

Cosa succede quando il documento o il prodotto viene rinominato?

La risposta HTTP 301 (spostata) è stata progettata per questo scopo. Se un client passa al vecchio URI, è sufficiente inviare loro il nuovo URI e possono reindirizzare a quello.

Il bit per porte scorrevoli non è univoco e appena generato dal titolo del video, potrebbe essere verificato su GET, quindi se si inseriscono le porte scorrevoli e non corrispondono a ciò che è veramente nel documento 287171, risponde 404.

Se seguo correttamente questo è un lavoro di duplicazione, hai un identificatore di nome per la risorsa e un ID nello stesso URI. Non serve a nulla.

Se sei preoccupato per più film con lo stesso nome, puoi aggiungere ulteriori informazioni sul film nell'URL

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

o

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

Detto questo, non c'è niente di sbagliato nell'utilizzare gli ID se questo ha senso per il tuo modello di dati, in particolare se l'unica cosa che stai raggruppando è che sono video.

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

Il client, che sia un computer o un utente umano, non dovrebbe fare troppo affidamento sulla struttura dell'URI in primo luogo, dovrebbe guardare il contenuto che è stato restituito per capire quale risorsa trovare.

Non c'è nulla di sbagliato nell'avere un sistema URI sensibile che rende facile per qualcuno indovinare semplicemente la posizione di una risorsa o navigare su e giù per la struttura in base alle proprietà condivise (cioè tutti i film nel 2004), ma il tuo sistema non dovrebbe fare affidamento su questo e nessun client dovrebbe rompersi se cambi i tuoi URI

O per dirla in altro modo, dovresti essere in grado di cambiare durante la notte

http://vidsyeah.com/video/studios/paramount/sliding_doors

a

http://vidsyeah.com/video/12323

e nessun client dovrebbe interrompere perché i client dovrebbero guardare il contenuto e non gli URL.

— Cormac Mulhall
fonte

Come la risposta di Jon, penso che non stai indossando il tuo cappello UX quando ci pensi. Voglio aumentare l'usabilità dell'indirizzo. Vedi il mio commento alla domanda: "Mi piacciono gli URL amichevoli poiché hai un'idea di cosa si trova alla fine dell'URL quando passi il mouse o lo visualizzi in un'e-mail o in un documento. È meglio per SEO o lo era."

— Luke Puplett,

2

Per lanciare un 301, dovrei essere in grado di cercare la risorsa corretta, quindi avrei bisogno di una storia.

— Luke Puplett,

1

Avresti bisogno di una cronologia, ma se hai un sito con risorse che cambiano è comunque una buona idea.

— Cormac Mulhall,

Non ci sono problemi con URI amichevoli. Non farei lo schema secondo cui l'URI può essere tutt'altro che funzionante se alla fine ha un ID. Ciò non risolve davvero alcun problema (l'utente deve ancora ricordare l'ID) e introduce uno schema URI confuso (l'utente potrebbe legittimamente chiedere perché due URI diversi, uno con un errore di ortografia, vanno alla stessa risorsa)

— Cormac Mulhall

1

Se sei preoccupato per gli errori di ortografia negli URI, un modo comune per gestirlo è l'URI suggerito nella pagina di errore 404 per l'URL scritto in modo errato. È possibile eseguire una ricerca del modello di parole e restituire ciò che si pensa che l'utente stia cercando.

— Cormac Mulhall,

1

La BBC usa lumache che sono:

alfanumerico (per compattezza)
unico (per le ricerche)
non sequenziale (in modo che l'ordine le cose vengano aggiunte al db non sia esposto)

ad es. http://www.bbc.co.uk/programmes/b006mk7h

Ogni programma pubblico ha sia un ID che una lumaca. Gli ID possono quindi essere interi con incremento automatico come al solito e gli spazi vuoti non vengono esposti.

— Nicholas Shanks
fonte

0

Da un punto di vista RESTful, gli URI dovrebbero seguire una struttura gerarchica prevedibile e perenne per migliorare l'usabilità.

Ciò li renderà più facili da usare per i consumatori. Se i tuoi dati hanno relazioni, sarebbe necessaria una sorta di gerarchia.

Sembra che lo schema sia: \video\[name]\[id]

Se il nome non viene utilizzato per ulteriori classificazioni, potrebbe essere eliminato \video\[id].

Tuttavia, se desideri classificare i video, forse il nome è utile.

Esempi:

\ video \ SwingingDoors \ 123
\ video \ SwingingDoors \ 124
\ video \ SCORREVOLE_ \ 125
\ video \ SCORREVOLE_ \ 126

È davvero una decisione di progettazione su come si modella l'accesso.

— Jon Raynor
fonte

Penso che tu ci stia pensando da un'architettura di informazioni API / sito PoV. Stavo cercando di introdurre una parte URL amichevole generata per aiutare gli esseri umani e il SEO. Apparentemente questa è una cosa comune e si chiama "lumaca". Il nome non viene utilizzato per la classificazione e viene aggiunto (non eliminato) per creare una UX migliore con l'URL e il nostro sito / marchio.

— Luke Puplett,