Débat : URL Rewriting, avec ou sans ID ?

Pandore a écrit :
Par contre, ça non.
Ces sites servent justement d'espace de stockage et de téléchargement. Tout le monde n'a pas forcément envie d'encombrer son espace de stockage perso avec des fichiers inutiles.
Qu'est-ce qui te gêne ? La pub qui y est présente ? Le chrono d'attente en mode gratuit avant de pouvoir télécharger ?

C'est pas une question de compréhension, mais un simple choix : ce site est lent, j'aime pas le concept, j'ai rarement confiance dans ce qui y est uploadé (bien que sous Mac je ne craigne pas grand chose), y'a trop de pub, c'est long, etc etc...

La question n'est pas réellement "est-il compréhensible d'uploader sur MU ?" mais plutôt "est ce que je peux m'en passer, et si oui dois-je m'en justifier ?" J'aime pas ce site... Jusqu'à preuve du contraire j'ai le droit donc je ne l'utilise pas, et je préfère savoir quand un lien m'y emmène pour l'éviter, tout simplement

Dans un autre genre, je vais très rarement sur Dailymotion, parce que mon Mac supporte très mal le flash, et encore moins sous Safari, je suis donc obligé de couper certains autres logs et utiliser Opéra pour pouvoir lire des vidéos... DOnc si c'est Daily, à moins que ça n soit vraiment une vidéo rare et intéressante... Je vais voir ailleurs ! Certains sites jouissent d'une réputation mais d'une qualité pas forcément optimale et inversement, bizarrement je ne rame absolument pas quand je regarde une loooooooongue vidéo en HD sur Vimeo !



Tout ça pour dire que plus on navigue plus, je pense, on trouve des sites sur lesquels on est enclins à aller et d'autre ou on rechigne... et une URL claire peut permettre de faire, je pense la différence quand on cumule "j'aime pas ce site" + intitulé du lien pas explicite + auteur peu fiable etc etc...

@LD : Ah parce qu'une BP à ce sujet a été refusée récemment ?

ça a été envisagé, mais cela pose divers problèmes, dont ceux liés aux services embarqués et autres applications tierces. Et plus généralement l'impossibilité de définir un critère vérifiable.

Tiens, pour prendre un exemple immédiat, comment traiter en évaluation ces deux URL de cette page de forum :
* forum.alsacreations.com/topic-9-47144-3-Debat--URL-Rewriting-avec-ou-sans-ID-.html
* forum.alsacreations.com/posting.php?action=edit&pid=331993&tid=47144&fid=9&p=3

La première est-elle explicite ? La seconde invalide-t-elle le critère pour le site ?

La BP retenue demande uniquement que La syntaxe des URL soit homogène sur l'ensemble du site (elle a elle-même du plomb dans l'aile, d'ailleurs, tiens).
Modifié par Laurent Denis (10 Mar 2010 - 12:10)

C'est vrai que définir ce qui est explicite et ce qui ne l'est pas n'est pas de la logique binaire. C'est forcément sujet à interprétations.... quelque chose qui paraîtra explicite pour quelqu'un ne le sera peut-être pas pour quelqu'un d'autre.

Bonjour,

Pour aller dans le même sens que HammHetfield, si l'url est une url de type tinyurl, je passe mon chemin. Alors il faut croire qu'à un moment ou un autre, l'url d'un lien a son importance (nom de domaine, nom de la page, extension...).

Tony Monast a écrit :
Pour aller dans le même sens que HammHetfield, si l'url est une url de type tinyurl, je passe mon chemin. Alors il faut croire qu'à un moment ou un autre, l'url d'un lien a son importance (nom de domaine, nom de la page, extension...).

Personnellement, c'est pas tant la forme des URL qui me chagrine. Je vérifie au plus le nom de domaine et hTTP ou HTTPS si je fais une opération sensible. Pour le reste, c'est vrai que c'est pratique de pouvoir retaper une URL dont on peut se souvenir, mais c'est pas dramatique : les marques-page sont faits pour ça.

En revanche ce qui me gêne un peu plus, et c'est encore plus accentué avec les URL raccourcies du genre bit.li ou tinyurl, c'est de ne pas savoir du tout sur quoi on tombe quand on clique sur un lien.
Par exemple, les liens qui ouvrent des PDF et qui ne sont pas signalés explicitement. Adaube reader est un logiciel de m***, lent, buggé, et ça m'énerve quand il s'ouvre sans crier gare en mobilisant 100% du proc pendant 2 minutes sans me laisser le choix (sauf de le tuer sauvagement) pour ouvrir un PDF de 100 pages alors que je m'attendais à ouvrir une simple page HTML.
Idem avec des liens vers des vidéos youtube qui démarrent automatiquement ou avec d'autres types de fichiers non HTML (ouvrir word ou excel non plus c'est pas forcément très rapide). Le type de la ressource cible n'est pas toujours déductible du contexte.

Vraiment, ça me désole que l'attribut type de <a> n'ait jamais été exploité et ne le sera sans doute jamais. Personne ne s'est donc jamais préoccupé de ça, tout le monde s'en fiche, ou bien je ne suis pas normal ?

Note : je me lamente sur adaube reader mais inutile de me proposer d'autres alternatives pour lire des PDF : je n'ai pas le choix. Inutile non plus de me proposer open office, je n'ai pas le choix non plus.
Modifié par QuentinC (11 Mar 2010 - 08:56)

QuentinC a écrit :
Note : je me lamente sur adaube reader mais inutile de me proposer d'autres alternatives pour lire des PDF : je n'ai pas le choix. Inutile non plus de me proposer open office, je n'ai pas le choix non plus.

Par contre un navigateur qui n'ouvre pas automatiquement ces formats de document mais demande ce que tu veux en faire, ça c'est possible. Il suffit de désinstaller les plugins Adobe Reader (et équivalent éventuel pour Office) des navigateurs, et éventuellement de configurer des associations de fichiers (Firefox).

D'un point de vue de performances pures, il sera toujours plus rapide de faire un lookup à partir d'un id qu'à partir d'un string (même si le champ slug est stocké dans la base et indexé). Après oui, ça se joue pas à beaucoup et ça ne commence à peser que sur un site avec plusieurs centaines de milliers d'entrées et à fort trafic.
Et encore, avec autant de trafic, il y a de bien meilleures manières d'optimiser (comme un cache html par exemple) que cette micro-optimisation.

Ensuite, l'argument esthétique de l'url avec un id Vs url sans id peut se défendre (en admettant que les utilisateurs y pretent réellement attention). Mais comme il a été évoqué, si plusieurs pages ont le même slug (du fait des simplifications d'url), il faut rajouter un numero à la fin pour les différencier et en ce cas, on revient au problème original.
Quel est le plus "joli" entre /blog/42-lol-mon-chat-est-trop-choupinou.html et /blog/lol-mon-chat-est-trop-choupinou-02.html ?

Ajoutez à ça le cauchemar que peut rapidement devenir l'assignation de slug quand on modifie ou supprime des articles existants. Rester avec un id me semble vraiment le plus simple.

Après, on peut toujours mettre l'id dans son propre repertoire de l'url, plutot que dans le nom du fichier. C'est plus pratique si je veux télécharger la ressource, cela me fait un fichier mieux nommé sur mon disque dur.
Imaginez que vous génériez sur votre site des factures en PDF pour vos clients (ça marche aussi pour des images uploadées par exemple). Si l'utilisateur veut le télécharger et que l'url est

/facture/154562-facture-2010-03.pdf

Il va se retrouver avec un fichier nommé

154565-facture-2010-03.pdf

, ce qui n'a pas beaucoup de sens pour lui, vu qu'il se moque de l'id de sa facture dans votre base de donnée.
En nommant le lien

/facture/154565/facture-2010-03.pdf

, il aura un fichier plus facile à comprendre et qui se classera par ordre chronologique facilement avec ses autres fichiers.

Personnellement, la structure d'url que j'utilise (inspirée en grande partie du fait que je travaille avec cakePHP, framework MVC) est la suivante :

domain.com/controller/action/id/slug

Où controller est le type d'element que la page doit afficher comme "article", "realisations", "commentaire", "page", etc

Action est l'action que vous appliquez sur cet élément. Comme "lire", "imprimer", "editer", "ajouter", etc. Par défaut c'est lire (lire un post de blog, lire une page) et je supprime même complétement cette partie de l'url dans ces cas là.

Id est... je vous laisse deviner... l'id unique de l'élement dans ma base de données.

Et slug pour finir est purement cosmétique et me sert avant tout pour avoir des url seo-friendly et descriptives.

Ce qui me donne des urls de ce genre là :
domain.com/article/42/mon-chat-est-cromeugnon.html pour lire l'article en question
domain.com/article/edit/42 pour éditer l'article (le slug est inutile ici)
domain.com/article/add/ pour ajouter un nouvel article
domain.com/article/pdf/42/mon-chat-est-cromeugnon.pdf pour générer une version en pdf

Et pour des elements ou des méthodes plus compliqués, qui ont besoin de plus de parametres, je peux créer des urls de ce type en passant plus de paramètres :
domain.com/article/recherche/keyword1/keyword2/keyword3/
domain.com/concerts/paris/rock/2010/

Ca me permet de garder une homogénéité des urls sur tout le site et de rester avec des règles .htaccess simples tout en permettant de passer pas mal de paramètres si nécessaire.

Et pour faire les choses bien, je vérifie aussi toujours que si un slug est passé, il match celui que j'ai dans ma base pour l'id en question. S'ils différent, je renvoie le code HTTP correct (je ne l'ai plus en tête. 301 je crois ?) indiquant que l'url a changé en retournant l'url exacte (avec le bon slug) de la page demandée.
Modifié par Tymlis (11 Mar 2010 - 10:15)

Très intéressante cette discussion.

A titre personnel, je regarde systématiquement les urls ds liens sur lesquels je cliques, à moins que je ne sache implicitement leur destination à partir des sites de confiance. je ne comprends même pas qu'on puisse masquer la barre d'état, si importante à mes yeux pour cette raison.

Florent V. a écrit :

Par contre un navigateur qui n'ouvre pas automatiquement ces formats de document mais demande ce que tu veux en faire, ça c'est possible. Il suffit de désinstaller les plugins Adobe Reader (et équivalent éventuel pour Office) des navigateurs, et éventuellement de configurer des associations de fichiers (Firefox).

Tu sous-entends qu'on ne peut pas désactiver l'ouverture automatique des PDF avec IE ?
Bref, effectivement, raison de plus pour que je me mette vraiment à firefox... plus rien ne m'en empêche techniquement, mais les habitudes demeurent.

bzh a écrit :
je ne connaissais pas, comment ça marche?

Un exemple vaut mieux qu'un long discours :
<a href="truc.pdf" type="application/x-pdf">...</a>
C'est sûrement pas le bon type MIME, mais l'idée c'est qu'on peut renseigner dans le lien lui-même la nature de la cible. Ça éviterait les clics inutiles et les désagréments que j'évoquais plus haut.
Malheureusement, personne n'en tient compte. Aucun navigateur ni aucune aide technique. ET pourtant.... c'est dans le standard.
Modifié par Hermann (13 Mar 2010 - 13:57)

QuentinC a écrit :

<a href="truc.pdf" type="application/x-pdf">...</a>
Malheureusement, personne n'en tient compte. Aucun navigateur ni aucune aide technique. ET pourtant.... c'est dans le standard.

Wow, je ne connaissais pas ça. Je viens de le rajouter à mon CMS.

Tymlis a écrit :


Si l'utilisateur veut le télécharger et que l'url est

/facture/154562-facture-2010-03.pdf

Il va se retrouver avec un fichier nommé

154565-facture-2010-03.pdf

, ce qui n'a pas beaucoup de sens pour lui, vu qu'il se moque de l'id de sa facture dans votre base de donnée.
En nommant le lien

/facture/154565/facture-2010-03.pdf

, il aura un fichier plus facile à comprendre et qui se classera par ordre chronologique facilement avec ses autres fichiers.

Bien tenté sauf qu'il y a toujours la possibilité de renommer le dit fichier à ta guise au moment de l'enregistrement.

QuentinC a écrit :
Pour le reste, c'est vrai que c'est pratique de pouvoir retaper une URL dont on peut se souvenir, mais c'est pas dramatique : les marques-page sont faits pour ça.

Je ne me suis jamais amusé à taper l'url d'une page interne de site directement dans la barre de navigation ! Heureusement que les favoris existent. D'ailleurs, je ne peux plus me passer de la recherche "intelligente" d'urls bookmarkées de Firefox ^^

darkstar2023 a écrit :
le net est avant tout un espace pratique d'informations et tout le monde n'a pas l'idée de faire des liens ultra explicites et parfaits caractèrement parlant.

C'est pour ça par exemple que certains sites/pages de sites se positionneront toujours mieux que d'autres dans les résultats de moteurs de recherche (c'est une des bases du référencement, même s'il n'y a pas que ça qui joue bien sur. Mais ça c'est une autre histoire )

HammHetfield a écrit :
C'est pas une question de compréhension, mais un simple choix : ce site est lent, j'aime pas le concept, j'ai rarement confiance dans ce qui y est uploadé (bien que sous Mac je ne craigne pas grand chose), y'a trop de pub, c'est long, etc etc...

Mis à part pour le problème de confiance des choses uploadées, tu as visiblement utilisé le service en mode gratuit. Même si télécharger un fichier avec un débit de 10k/s en "heures de pointe" ou voir de nouvelles fenêtres apparaitre n'est pas du tout plaisant, on ne peut pas avoir le beurre et l'argent du beurre, la bande passante ça a un coût.

HammHetfield a écrit :
La question n'est pas réellement "est-il compréhensible d'uploader sur MU ?" mais plutôt "est ce que je peux m'en passer, et si oui dois-je m'en justifier ?" J'aime pas ce site...

Je me suis sans doute fait mal comprendre. Ce que je voulais dire, c'est que malgré les contraintes que l'on peut voir en mode gratuit, ce genre de services d'hébergement de fichiers en tous genres a du succès auprès du public. Car c'est très simple d'utilisation, il n'y a pas besoin d'avoir un espace d'hébergement perso pour proposer des fichiers (ni faire le nettoyage après derrière), et c'est gratuit.

HammHetfield a écrit :
Tout ça pour dire que plus on navigue plus, je pense, on trouve des sites sur lesquels on est enclins à aller et d'autre ou on rechigne... et une URL claire peut permettre de faire, je pense la différence quand on cumule "j'aime pas ce site" + intitulé du lien pas explicite + auteur peu fiable etc etc...

M'ouais ... En regardant l'url survolée, tu ne peux pas savoir à l'avance par exemple si le nouveau site que tu vas visité a du flash ou pire est en full flash (chose qui me fait fuir direct). Autre exemple qui me vient à l'esprit, tu ne peux pas prévoir non plus les cas de redirections sauvages.

Sur ce, bon week-end à tous ^^

Tymlis a écrit :


Wow, je ne connaissais pas ça. Je viens de le rajouter à mon CMS.

Pas une bonne idée, ça.

Sur le fond : un navigateur va de toute façon faire une requête quand l'utilisateur active un lien. Le serveur va alors lui communiquer le type MIME de la ressource, le plus actualisé et pertinent possible (contrairement au contenu de cet attribut). Là, le navigateur (via une extension etc.) pourra réagir avec une liste de type de contenus correspondants à des formats non souhaités par son utilisateur.

Cet attribut est inutile et néfaste en ce qu'il reporte la charge du suivi des types de contenus liés sur les auteurs du lien : or, c'est une histoire qui ne se joue qu'entre le site qui publie la ressource et l'utilisateur qui veut y accéder. Je n'ai aucun rôle à y jouer quand je mets un lien dans une page Web.

Par ailleurs, les standards d'accessibilité demandent que le format des ressources en téléchargement soit explicitement précisé dans les libellés de liens (ou leur contexte, etc.). L'attribut est là encore inutile et néfaste : il va donner l'impression de répondre à l'exigence WCAG, alors qu'il ne le fait pas. Très mauvais CMS, du coup

<edit>Si vous voulez qu'on pousse le raisonnement un poil plus loin: oui, certains critères des méthodes d'application WCAG qui exigent que le format des données en téléchargement soit précisé explicitement sont, en théorie, critiquables : cela devrait relever des fonctionnalités des navigateurs et des aides techniques. Mais comme ce n'est pas le cas et que c'est une source de gêne importante pour les utilisateurs, comme le souligne l'exemple de Quentin...</>
Modifié par Laurent Denis (13 Mar 2010 - 10:24)

Florent V. a écrit :

Par contre un navigateur qui n'ouvre pas automatiquement ces formats de document mais demande ce que tu veux en faire, ça c'est possible. Il suffit de désinstaller les plugins Adobe Reader (et équivalent éventuel pour Office) des navigateurs, et éventuellement de configurer des associations de fichiers (Firefox).

Il me semble qu'il y a des cas de figure (me souviens plus lesquels désolé) ou le plug-in n'est pas suffisant pour afficher le PDF dans le navigateur.

Tymlis a écrit :

domain.com/article/ pdf/42/mon-chat-est-cromeugnon.pdf pour générer une version en pdf

C'est redondant, non ?

domain.com/article/42/mon-chat-est-cromeugnon.pdf est suffisant, avec le verbe GET pour le lire.

Moi j'aime pô les ID dans les URL; je trouve ça laid et je les évite au maximum. Quand je suis sûr de ne pas avoir de doublon, je n'en mets pas, et je construis un nom unique avec un index pour faciliter la recherche dans la BDD. Mais bon, c'est mon choix à moi.

Lanza a écrit :


C'est redondant, non ?

domain.com/article/42/mon-chat-est-cromeugnon.pdf est suffisant, avec le verbe GET pour le lire.

Oui, mais non aussi.

Si domain.com/article/ pdf/ donne accès au sommaire de toutes les versions PDF...

Bref, il y a mille et une stratégies possibles, et aucune bonne pratique ou ligne de conduite exclusive possible. Chacun pourra y aller ici de sa solution préférée sans que cela n'avance d'un quart de poil
Modifié par Laurent Denis (13 Mar 2010 - 16:09)

C’est vrai.

Cependant, je me demande dans quelle mesure la profusion d’URL longues et composées de suites de caractères improbables n’est pas à l’origine du refus de certains internautes d’utiliser la barre d’adresse. Et ceux-là finissent par confier aveuglément à Google et aux liens le soin de les amener à destination, avec les conséquences que l’on sait.

Et donc – sorry, j’avais perdu le fil – j’ai tendance à les raccourcir au maximum de ce que je peux. Ça reste un choix tout à fait personnel et je ne prétends pas que l’on puisse en dégager une bonne pratique, ni un schéma universel, juste une opinion qui peut aider d’autres à faire un choix .

Et pendant que j’y suis, autant livrer ma réflexion en intégralité.
Les URL ont tendance pour des raisons historiques, à refléter l'arborescence du système de fichiers sur le serveur, ce qui peut être une bonne idée, mais devrait rester un cas particulier ; la façon dont on organise nos scripts n'ayant en général rien, ou peu, à voir avec l'architecture du site. Les frameworks du genre Rails, Django – ou leurs pâles copies en PHP – ont l'avantage de ne pas proposer ce choix par défaut.

Quant à mettre un id, ou pas, mon choix est dicté par les critères suivants :
– l’auteur de la ressource : moi, un rédacteur attitré, un internaute, etc.
– le type de contenu de ladite ressource ;
– le nombre anticipé de ressources sous la même racine ;
- le risque de doublons.

Si j’en suis l’auteur, et que le contenu le permet, j'essaie de ne pas mettre d'id, ni même un titre, mais une expression clef… De préférence la plus proche possible de ce qu'un internaute qui chercherait à consulter ma ressource taperait dans un moteur de recherche ; courte et explicite.

Si je ne suis pas l'auteur, je décide en fonction des capacités présumées du redacteur : création automatique à partir du titre, ou expression clef, s’il est capable d'en comprendre la démarche.

Si c'est l'internaute, il est difficile de se passer d'un id, on ne peut pas demander à son visiteur de vérifier que personne n’a utilisé le même titre, ni d’entrer une expression spécifique. Dans ce cas, j’essaie de nettoyer le titre au maximum (je honnis les « -- »), et je le double d'un id.

Enfin, si le contenu n'a pas de « titre », comme une image sans légende ni texte alternatif – et il y a de bonnes raisons de le faire –, j’utilise un id.

Voilà.
Modifié par Lanza (13 Mar 2010 - 17:59)