Fournir des URL conviviales pour un site Web par rapport aux réalités des ID de base de données

24

Nous avons une base de données de ressources, que ce soit des produits, des articles de blog ou quelque chose du genre. Nous devons concevoir un schéma d'URL pour les résoudre, pour le site Web public.

Voici deux exemples liés à l'ID de base de données:

Voici un exemple convivial:

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

(Un petit aperçu de ma vie de navigation là-bas)

J'aime les URL conviviales car vous avez une idée de ce qui se trouve à la fin de l'URL lorsque vous survolez ou voyez-le dans un e-mail ou un document. C'est mieux pour le SEO, ou c'était le cas auparavant.

Que se passe-t-il lorsque le document ou le produit est renommé? Soit parce qu'il a changé (le wiki peut ne pas changer mais nos ressources le pourraient) soit à cause d'une faute de frappe, non? Nos ressources sont très techniques, longues et sujettes aux erreurs.

De plus, nous avons un ID de base de données, qui est un nombre. Regardons une idée pour une adresse d'une vidéo en utilisant un magasin de location de simulation:

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

L'ID est évident et est utilisé dans la recherche de base de données. Bien.

Le bit de portes coulissantes n'est pas unique et vient d'être généré à partir du titre de la vidéo, il pourrait être vérifié sur GET, donc si les portes coulissantes ont été entrées et ne correspondent pas à ce qui est vraiment dans le document 287171, il répond 404.

Ou peut-être que cela pourrait être ignoré, permettant aux humains de coller ce qu'ils veulent là-dedans, si quelqu'un s'en souciait. Cette URL fonctionnerait donc également:

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

Le problème avec la vérification de la partie conviviale est, comme mentionné, le problème du renommage ou de la correction de faute de frappe. Si le nom a changé, et dans notre domaine cela se produit, nous ne voulons pas casser les URL qui existent, alors devrions-nous:

Il suffit de ne pas vérifier la partie amicale.
Vérifiez, mais ajoutez un «historique» des parties conviviales à l'enregistrement de la base de données pour que tous les ID conviviaux précédents fonctionnent toujours!

Vos pensées et idées sont les bienvenues.

Luc

— Luke Puplett
source

11

même ce site utilise une combinaison http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(en utilisant une version non vérifiée à la lumière des changements de titre, le lien de partage plus court n'est que l'identifiant: http://programmers.stackexchange.com/q/255684/25768(et l'identifiant utilisateur pour le suivi des badges)

— ratchet freak

11

Si vous avez un identifiant unique dans votre URL, je ne vois pas pourquoi vous voudriez vérifier la partie slug du tout. Utilisez-le pour les looks et ignorez-le pour les recherches.

— thorsten müller

Si l'un de vous souhaite donner une réponse correcte, je vote pour que vous obteniez les points. Je vais laisser les votes entrer et attribuer la réponse aux plus votés dans quelques jours.

— Luke Puplett

1

programmers.stackexchange.com/questions/231483/…

— gnat

3

Je n'ai jamais connu le terme limace auparavant. Je devais être sous un rocher. Geddit?

— Luke Puplett

6

Conserver l'ID dans l'URL est la méthode la plus évolutive et, comme vous l'avez démontré, les URL peuvent toujours être relativement bonnes.

Une autre option utilisée par plusieurs projets consiste à conserver un historique des limaces précédemment utilisées. Lorsque le titre change, vous mettez à jour le slug et si quelqu'un essaie de rechercher un slug obsolète, recherchez dans la liste des anciens slugs. De cette façon, les anciens slugs peuvent être réutilisés pour du nouveau contenu (ou non selon votre implémentation).

Wordpress l'a fait, tout comme le joyau friendly_id, qui est probablement le joyau le plus utilisé pour gérer les identifiants conviviaux pour Rails.

De plus, même si j'aime les URL de bonne apparence, je pense qu'il est important de se rappeler qu'il s'agit très probablement d'une fonctionnalité utilisée par les utilisateurs plus avertis en technologie. Certains navigateurs commencent même à masquer des URL (ou une partie de celles-ci).

— mbillard
source

2

Cette histoire de limace est ce que je considérais. Depuis la publication de la question, j'ai remarqué que de nombreux grands sites nommés ont un slug qui n'est pas vérifié, vous pouvez le modifier pour dire n'importe quoi. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 fonctionne. StackExchange est intelligent car il «corrige» et redirige le navigateur pour s'assurer que le bon lien est affiché et partagé.

— Luke Puplett

Un "slug" est moins utile pour les gens, et plus utile pour l'optimisation des moteurs de recherche, car un "slug" ou une "URL conviviale" devrait avoir des mots clés liés au contenu de la page. Les utilisateurs avancés ne sont pas la raison pour inclure des URL conviviales dans votre site. Les classements des moteurs de recherche ont tendance à être la principale raison.

— Greg Burghardt

Je ne suis pas d'accord. Les URL avec seulement des identifiants sont difficiles à utiliser; il est difficile de se souvenir d'une liste d'entre eux à laquelle vous voudrez peut-être revenir. Ou s'il y aura quelque chose d'inapproprié à l'autre bout du lien. La barre d'adresse de Chrome suggère également n'importe quelle partie de l'URL, ce qui est utile.

— Luke Puplett du

1

@LukePuplett yes Je pense que la façon dont SE traite les URL est la plus simple en ce qui concerne les limaces.

— mbillard

@GregBurghardt la seule différence est dans le taux de clics, les utilisateurs ont tendance à cliquer un peu plus sur les URL conviviales: stackoverflow.com/questions/505793/…

— mbillard

3

J'ai utilisé deux scénarios différents dans le passé.

/id/some-slugoù le idest utilisé pour rechercher , pas la limace. Ainsi, la limace peut être n'importe quoi . Mais, lorsque le slug ne correspond pas au slug réel, l'utilisateur est redirigé vers la version actuelle.
/permalinkpour les cas où nous ne voulions pas d'un identifiant dans l'url ou où l'url ne devrait jamais changer, même si un identifiant est disponible (voir [1] et [2] ). Bien sûr, dans ce cas, le permalinkest utilisé pour la recherche . Le slug actuel et le permalien (le premier slug) sont stockés dans la base de données.

Dans aucune de ces façons, vous devez conserver un historique des limaces dans votre base de données, ce qui pourrait devenir problématique très bientôt.

ps: Dans le deuxième cas, vous aurez besoin d'un routage très spécifique pour conserver les crédits sociaux:

si vous le souhaitez, redirigez les utilisateurs vers l'URL actuelle (non permalien)
avoir le permalien utilisé comme URL dans les boutons sociaux
redirigez toujours le robot d'exploration Facebook vers le permalien

Voir à nouveau [1] et [2] .

— Filon
source

Pourquoi ce sera problématique? Si je garde et que ID et slug est quelque chose, le visiteur ira à la page réelle. Sera-ce nuisible pour le référencement?

— Jnanaranjan

Vous voulez dire garder un historique des limaces? Que faites-vous lorsque quelqu'un veut réutiliser une telle limace? Pour le même ou un autre identifiant? Comment concevez-vous la base de données et / ou le code pour éviter les redirections multiples? Voulez-vous masquer l'existence après la suppression et les redirections exposent-elles l'existence précédente? Tout cela n'est pas impossible, mais cela soulève toutes sortes de questions que j'évite plutôt par conception.

— Lode

Ce que je voulais dire, c'est que si l'ID est présent dans l'URL, peu importe le slug, il sera redirigé vers la page demandée. Ensuite, l'histoire des limaces n'a pas d'importance. Je suis d'accord pour dire que c'est problématique pour Android.

— Jnanaranjan

1

Ah ok. C'est ce que j'ai ajouté un scénario 1 non? Ou voulez-vous dire autre chose?

— Lode

Oui. C'est exact.

— Jnanaranjan

2

Que se passe-t-il lorsque le document ou le produit est renommé?

La réponse HTTP 301 (déplacée) a été conçue à cet effet. Si un client accède à l'ancien URI, il vous suffit de lui envoyer le nouvel URI et il peut le rediriger.

Le bit de portes coulissantes n'est pas unique et vient d'être généré à partir du titre de la vidéo, il pourrait être vérifié sur GET, donc si les portes coulissantes ont été entrées et ne correspondent pas à ce qui est vraiment dans le document 287171, il répond 404.

Si je suis bien, c'est du travail en double, vous avez à la fois un identifiant de nom pour la ressource et un identifiant dans le même URI. Cela ne sert à rien.

Si vous craignez que plusieurs films aient le même nom, vous pouvez ajouter des informations supplémentaires sur le film dans l'URL

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

ou

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

Cela dit, il n'y a rien de mal à utiliser des identifiants si cela a du sens pour votre modèle de données, en particulier si la seule chose que vous regroupez est qu'ils sont des vidéos.

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

Le client, que ce soit un ordinateur ou un utilisateur humain, ne doit pas trop dépendre de la structure URI en premier lieu, il doit regarder le contenu que vous avez renvoyé pour déterminer quelle ressource trouver.

Il n'y a rien de mal à avoir un système d'URI sensible qui permet à quelqu'un de deviner simplement l'emplacement d'une ressource ou de naviguer dans la structure en fonction des propriétés partagées (c'est-à-dire tous les films en 2004), mais votre système ne doit pas compter à ce sujet et aucun client ne devrait casser si vous modifiez vos URI

Ou, pour le dire autrement, vous devriez pouvoir changer la nuit de

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

à

http://vidsyeah.com/video/12323

et aucun client ne doit s'arrêter car les clients doivent regarder le contenu et non les URL.

— Cormac Mulhall
source

Comme la réponse de Jon, je pense que vous ne portez pas votre chapeau UX quand vous y pensez. Je veux augmenter l'utilisabilité de l'adresse. Voir mon commentaire dans la question: "J'aime les URL conviviales car vous avez une idée de ce qui se trouve à la fin de l'URL lorsque vous survolez ou voyez-le dans un e-mail ou un document. C'est mieux pour le référencement, ou c'était le cas."

— Luke Puplett

2

Afin de lancer un 301, je devrais être en mesure de rechercher la bonne ressource, donc j'avais besoin d'un historique.

— Luke Puplett

1

Vous auriez besoin d'un historique, mais si vous avez un site avec des ressources qui changent, c'est quand même une bonne idée.

— Cormac Mulhall

Il n'y a aucun problème avec les URI amicaux. Je ne ferais pas le schéma selon lequel l'URI peut être autre chose que fonctionner si elle a un ID à la fin. Cela ne résout vraiment aucun problème (l'utilisateur doit toujours se souvenir de l'ID) et introduit un schéma d'URI déroutant (l'utilisateur peut légitimement demander pourquoi deux URI différents, l'un avec une faute d'orthographe, vont à la même ressource)

— Cormac Mulhall

1

Si vous êtes préoccupé par les fautes d'orthographe dans les URI, une manière courante de résoudre ce problème est les URI suggérés dans la page d'erreur 404 pour l'URL mal orthographiée. Vous pouvez faire une recherche de modèle de mot et redonner ce que vous pensez que l'utilisateur pourrait rechercher.

— Cormac Mulhall

1

La BBC utilise des slugs qui sont:

alphanumérique (pour la compacité)
unique (pour les recherches)
non séquentiel (pour que l'ordre des éléments ajoutés à la base de données ne soit pas exposé)

par exemple http://www.bbc.co.uk/programmes/b006mk7h

Chaque programme public a à la fois un identifiant et un slug. Les ID peuvent alors être des incréments à incrémentation automatique comme d'habitude, et les lacunes ne sont pas exposées.

— Nicholas Shanks
source

0

Du point de vue RESTful, les URI doivent suivre une structure hiérarchique prévisible et peut-être pour améliorer la convivialité.

Cela les rendra plus faciles à utiliser par les consommateurs. Si vos données ont des relations, une sorte de hiérarchie serait nécessaire.

Il semble que le schéma soit: \video\[name]\[id]

Si le nom n'est pas utilisé pour une autre classification, il pourrait être supprimé en faveur de \video\[id].

Cependant, si vous souhaitez classer les vidéos, le nom est peut-être utile.

Exemples:

\ video \ SwingingDoors \ 123
\ video \ SwingingDoors \ 124
\ video \ SlidingDoors \ 125
\ video \ SlidingDoors \ 126

C'est vraiment une décision de conception sur la façon dont l'accès est modélisé.

— Jon Raynor
source

Je pense que vous pensez à cela à partir d'un PoV d'architecture d'informations API / site. Je cherchais à introduire une partie URL conviviale générée pour aider les humains et le référencement. Apparemment, c'est une chose courante et s'appelle «limace». Le nom n'est pas utilisé pour la classification et est ajouté (non supprimé) pour faire un meilleur UX avec l'URL et notre site / marque.

— Luke Puplett