web-dev-qa-db-fra.com

Un trait d'union, un trait de soulignement ou camelCase en tant que délimiteur de mots dans les URI?

Je conçois une API basée sur HTTP pour une application intranet. Je me rends compte que c’est un problème assez peu important dans l’ordre des choses, mais: devrais-je utiliser des tirets, des traits de soulignement ou camelCase pour délimiter des mots dans les URI?


Voici mes premières pensées:

camelCase

  • problèmes possibles si le serveur est insensible à la casse
  • semble avoir une utilisation assez répandue dans les clés de chaîne de requête ( http://api.example.com ? searchQuery = .. .), mais pas dans d'autres parties d'URI

Trait d'union

  • plus esthétique que les autres alternatives
  • semble être largement utilisé dans la portion de chemin de l'URI
  • jamais vu clé de chaîne de requête avec trait d'union à l'état sauvage
  • éventuellement meilleur pour le référencement (cela peut être un mythe)

Soulignement

  • potentiellement plus facile pour les langages de programmation à gérer
  • plusieurs API populaires (Facebook, Netflix, StackExchange, etc.) utilisent des traits de soulignement dans toutes les parties de l'URI.

Je me penche vers des traits de soulignement pour tout. Le fait que la plupart des gros joueurs les utilisent est convaincant (voir https://stackoverflow.com/a/608458/36057 ).

403
Josh Johnson

Vous devez utiliser des traits d'union dans une URL d'application Web analysable. Pourquoi? Parce que le trait d'union sépare les mots (afin qu'un moteur de recherche puisse indexer les mots individuels), et n'est pas un caractère Word . Le trait de soulignement est un caractère Word, ce qui signifie qu'il doit être considéré comme faisant partie d'un mot.

Double-cliquez dessus dans Chrome: camelCase
Double-cliquez sur ceci dans Chrome: under_score
Double-cliquez sur ceci dans Chrome: trait d'union

Voyez comment Chrome (j'entends aussi Google créer un moteur de recherche) pense que l'un de ces mots est deux?

camelCase et underscore obligent également l'utilisateur à utiliser le shift touche, alors que hyphenated ne le fait pas.

Donc, si vous devriez utiliser des traits d'union dans une application Web analysable, pourquoi voudriez-vous vous occuper de faire quelque chose de différent dans une application intranet? Une chose de moins à retenir.

399
Neil McGuigan

La meilleure pratique standard pour les API REST consiste à avoir un trait d'union , et non un camelcase ou des traits de soulignement.

Cela vient du "Livre de règles de conception d'API REST" de Mark Masse à Oreilly.

De plus, notez que Stack Overflow lui-même utilise des traits d'union dans l'URL: .../hyphen-underscore-or-camelcase-as-Word-delimiter-in-uris

De même que WordPress: http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-tknow-to-program-not-that-much- en fait

170
Al Sweigart

Alors que je recommande des traits d'union, je vais aussi postuler une réponse qui ne figure pas sur votre liste:

rien du tout

  • L'API de mon entreprise a des URI tels que /quotationrequests/, /purchaseorders/, etc.
  • Bien que vous disiez que c'était une application intranet, vous avez indiqué que le référencement était un avantage. Google correspond au modèle/foobar/dans une URL pour une requête de ?q=foo+bar
  • J'espère vraiment que vous n'envisagez pas l'exécution d'un appel PHP à une chaîne quelconque que l'utilisateur transmet à la barre d'adresse, comme @ Suggère ServAce85!
27
Nicholas Shanks

En général, cela n'aura pas assez d'impact pour s'inquiéter, d'autant plus qu'il s'agit d'une application intranet et non d'une application Internet à usage général. En particulier, comme il s’agit d’un intranet , le référencement n’est pas une préoccupation, car votre intranet ne devrait pas être accessible aux moteurs de recherche. (et si c'est le cas, ce n'est pas une application intranet).

Et tout framework digne de ce nom a déjà un moyen par défaut de le faire ou est assez facile de changer la façon dont il traite les composants d'URL à mots multiples. Je ne m'inquiéterais donc pas trop de cela.

Cela dit, voici comment je vois les différentes options:

trait d'union

  • Le plus grand danger pour les traits d'union est que le même caractère (généralement) est également utilisé pour la soustraction et la négation numérique (c'est-à-dire moins ou négatif ).
  • Les traits d'union sont pénibles dans les composants de l'URL. Ils semblent n'avoir de sens qu'à la fin d'une URL pour séparer les mots dans le titre d'un article. Ou, par exemple, le titre d'une question de débordement de pile qui est ajoutée à la fin d'une URL à des fins de référencement et de clarté de l'utilisateur.

nderscore

  • Encore une fois, ils se sentent mal dans les composants URL. Ils interrompent le flux (et la beauté/simplicité) d'une URL, car ils ajoutent essentiellement un grand espace apparent lourd au milieu d'une URL propre et fluide.
  • Ils ont tendance à se fondre dans les soulignés. Si vous vous attendez à ce que vos utilisateurs copient-collent vos URL dans MS Word ou d'autres programmes d'édition de texte similaires, ou à tout autre endroit susceptible de capturer une URL et de lui donner un soulignement (comme des liens traditionnellement sont), vous voudrez peut-être éviter les caractères de soulignement comme séparateurs de Word. En particulier, une URL soulignée avec des traits de soulignement a tendance à ressembler à des espaces à la place des traits de soulignement, en particulier lorsqu'elle est imprimée.

CamelCase

  • De loin mon préféré, car cela donne l'impression que les URL coulent mieux et ne présente aucun des défauts que les deux options précédentes ont.
  • Peut être légèrement plus difficile à lire pour les personnes qui ont de la difficulté à différencier les majuscules des minuscules, mais cela ne devrait pas poser trop de problèmes dans une URL, car la plupart des "mots" doivent être des composants d'URL et séparés par un / de toute façon. Si vous constatez que votre composant URL compte plus de 2 mots, vous devriez probablement essayer de trouver un meilleur nom pour ce concept.
  • Il ( a un problème possible avec la sensibilité à la casse, mais la plupart des plates-formes peuvent être ajustées pour être sensibles à la casse ou insensibles à la casse. N'importe quel c'est seulement vraiment un problème pour 2 cas: a.) Les humains tapant l'URL dans, et b.) Les programmeurs (puisque nous ne sommes pas humains) dactylographiant l'URL dans. Les typos sont toujours un problème, quelle que soit la sensibilité à la casse, ce n'est donc pas différent de tous les cas.
17
cdeszaq

voici le meilleur des deux mondes.

J'aime aussi "souligner" les soulignements, en plus de tous vos points positifs, il y a aussi un certain style old school.

Donc, ce que je fais est d'utiliser des traits de soulignement et d'ajouter simplement une petite règle de réécriture au fichier .htaccess de votre Apache pour réécrire tous les traits de soulignement en traits d'union.

https://yoast.com/Apache-rewrite-dash-underscore/

0
user2597538