Trait d'union, trait de soulignement ou camelCase comme délimiteur de mot dans les URI?

477

Je conçois une API basée sur HTTP pour une application intranet. Je me rends compte que c'est une assez petite préoccupation dans le grand schéma des choses, mais: dois-je utiliser des tirets, des traits de soulignement ou camelCase pour délimiter les mots dans les URI?

Voici mes premières réflexions:

affaire de chameau

problèmes possibles si le serveur ne respecte pas 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 URI

Trait d'union

plus esthétique que les autres alternatives
semble être largement utilisé dans la partie chemin de l'URI
clé de chaîne de requête avec un trait d'union dans la nature
peut-être mieux pour le référencement (cela peut être un mythe)

Souligner

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

Je penche vers les soulignés pour tout. Le fait que la plupart des grands joueurs les utilisent est convaincant (voir https://stackoverflow.com/a/608458/360570 ).

— Josh Johnson
source

De tout ce que j'ai lu, vous devez utiliser des traits d' union , mais underscores semblent plus faciles à gérer.

— ServAce85

1

Je crois que les traits d'union étaient, à une époque, meilleurs pour le référencement. Ce n'est peut-être pas vrai maintenant, mais tant de gens l'ont adopté qu'il est plus largement accepté comme meilleure pratique. Les soulignements , d'autre part, peuvent être plus faciles à gérer dans la programmation principale. J'utilise PHP, il est donc beaucoup plus facile d'utiliser un trait de soulignement pour un nom de fonction qu'un trait d'union. camelCase est peut-être le plus facile à implémenter, mais sa lecture est souvent difficile. Enfin, je pense que vous aviez raison quand vous avez dit que vous n'en voyez jamais hyphenated query string in the wild. C'est généralement le moment de camelCase.

— ServAce85

Selon cette question, le soulignement n'est pas une option valide: stackoverflow.com/questions/3641722/…

— wytten

2

Possible en double de Y at - il des Lignes directrices de la convention de nommage pour les API REST?

— Aurora0001

Vous mentionnez des API populaires, j'aimerais en ajouter une: Google. Pour autant que je sache, Google n'utilise rien du tout entre les mots (vérifiez l'API Google Maps Distance Matrix par exemple).

— nbeuchat

473

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

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

Voyez comment Chrome (j'entends Google fait un moteur de recherche aussi) pense seulement que l'un d'entre eux est deux mots?

camelCaseet underscoreobligent également l'utilisateur à utiliser la shiftclé, alors hyphenatedqu'il ne le fait pas.

Donc, si vous devez utiliser des tirets dans une application Web explorable, pourquoi vous embêteriez-vous à faire quelque chose de différent dans une application intranet? Une chose de moins à retenir.

— Neil McGuigan
source

20

Mon Firefox 24 sur Windows 7 pense que «un trait d'union» est deux mots.

— Marcel Stör

9

et il se comporte de la même manière pour 'under_score'.

— Marcel Stör

18

toute convention pour le queryString, par exemple ?event_id=1ou ?eventId=1???

— user2727195

8

@ user2727195 Bien que les URL soient sensibles à la casse, la meilleure pratique consiste à utiliser des minuscules dans la mesure du possible, car cela supprime la possibilité d'erreurs de frappe.

— Nicholas Shanks

7

Réponse interactive :)

— wild_nothing

210

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

Cela vient du «REST API Design Rulebook» de Mark Masse d'Oreilly.

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

Tout comme WordPress: http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually

— Al Sweigart
source

3

Si vous regardez le chapitre sur les instructions de chaîne de requête dans le livre de règles de conception de l'API REST, vous remarquerez que les instructions varient selon la partie de la règle. Il n'y a pas de règle explicite sur la casse dans les chaînes de requête, mais vous constaterez que tous les exemples de la section sur les chaînes de requête que toutes les clés sont en cas de chameau.

— Michael Lang

1

Just FYI - "REST API Design Rulebook" a été publié en octobre 2011. Il est possible que les choses aient changé au cours des 8 dernières années.

— ChrisN

25

Bien que je recommande les tirets, je postulerai également une réponse qui ne figure pas sur votre liste:

Rien du tout

L'API de mon entreprise a des URI comme /quotationrequests/, /purchaseorders/etc.
Bien que vous ayez dit qu'il s'agissait d'une application intranet, vous avez cité le référencement comme 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 d'exécuter un appel PHP à une chaîne arbitraire que l'utilisateur transmet à la barre d'adresse, comme le suggère @ ServAce85!

— Nicholas Shanks
source

+1 pour indiquer un choix évident. Il supprime également les / quotationrequests / from / quotation / requests /.

— Josh Petitt

34

Ce qui est mauvais dans cette réponse, c'est que, du point de vue du référencement, il n'y a aucun moyen pour une machine de comprendre où se termine un mot et où commence un autre, donc ces informations sont perdues. C'est également difficile pour les lecteurs humains. Il vaut mieux avoir des séparateurs au niveau des mots que rien.

— Al Sweigart

3

@AlSweigart SEO n'est pas pertinent car il s'agit d'une application intranet derrière un mur de connexion.

— Nicholas Shanks

2

Je suis d'accord avec @ niel-mcguigan que même s'il s'agit d'une application intranet, si vous utilisez des tirets partout, c'est une chose de moins à retenir.

— Drew Goodwin

2

@DrewGoodwin Assez juste. Cependant, notez que j'ai dit "postuler" et non "recommander" :-) Et les domaines n'ont généralement pas de tirets, donc les utiliser dans les chemins est déjà une chose à retenir.

— Nicholas Shanks

18

En général, cela n'aura pas suffisamment d'impact à craindre, d'autant plus qu'il s'agit d'une application intranet et non d'une application Internet à usage général. En particulier, puisqu'il s'agit d'un intranet , le référencement n'est pas un problème, 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 cadre qui en vaut la peine a déjà une méthode par défaut pour le faire, ou il est assez facile de changer la façon dont il traite les composants d'URL multi-mots, donc je ne m'inquiéterais pas trop.

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

Trait d'union

Le plus grand danger pour les tirets 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 tirets se sentent maladroits dans les composants 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 Stack Overflow qui est ajoutée à la fin d'une URL à des fins de référencement et de clarté utilisateur.

Souligner

Encore une fois, ils se sentent mal dans les composants URL. Ils décomposent le flux (et la beauté / simplicité) d'une URL, car ils ajoutent essentiellement un grand espace apparent lourd au milieu d'une URL claire et fluide.
Ils ont tendance à se fondre dans les soulignements. 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 n'importe où ailleurs qui pourrait récupérer une URL et la styliser avec un soulignement (comme les liens le sont traditionnellement ), alors vous voudrez peut-être évitez les traits de soulignement comme séparateurs de mots. En particulier lors de l'impression, une URL soulignée avec des traits de soulignement a tendance à ressembler à des espaces à la place des traits de soulignement.

Affaire de chameau

De loin mon préféré, car il fait que les URL semblent mieux circuler et n'a aucun des défauts des deux options précédentes.
Peut être légèrement plus difficile à lire pour les personnes qui ont du mal à différencier les majuscules des minuscules, mais cela ne devrait pas être un gros problème 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 trouvez que vous avez un composant URL de plus de 2 "mots", vous devriez probablement essayer de trouver un meilleur nom pour ce concept.
Il ne un problème possible avec sensibilité à la casse, mais la plupart des plates - formes peuvent être ajustées pour être soit sensible à la casse ou insensible à la casse. Tout ce n'est vraiment un problème que pour 2 cas: a.) Les humains tapant l'URL, et b.) Les programmeurs (puisque nous ne sommes pas humains) tapant l'URL. Les fautes de frappe sont toujours un problème, indépendamment de la sensibilité à la casse, c'est donc pas différent que tous les cas.

— cdeszaq
source

13

Être en désaccord. Regardez SO, regardez tous les sites wordpress, regardez la plupart des sites de nouvelles, ils utilisent tous des tirets. De plus, le camel case mélange les cas, le web devrait être tout en minuscules à mon avis.

— Fabien Warniez

4

À mon avis, le Web devrait être insensible à la casse, en fait. En ce qui concerne la convention, si vous suivez l'approche des routes RoR (ruby on rails), vous utiliserez des traits de soulignement. Habituellement, je le fais pour le garder cohérent entre les itinéraires générés par les rails et mes itinéraires nommés. Néanmoins, je pense que pour moi le tiret est mieux lu que les soulignés.

— rpbaltazar

1

Peut-être ont-ils un moteur de recherche interne dans leur intranet?

— Juha Untinen

3

Être en désaccord. Vos deux arguments contre les tirets sont viciés. Il n'y a aucun danger à propos de la négation ou de la soustraction parce que nous parlons ici de la partie nom d'un tuple, vous ne devriez jamais fonctionner ou évaluer la partie nom d'un tuple pour les mathématiques ou la négation. Il n'y a rien de gênant à utiliser des traits d'union dans les URI car c'est une bonne pratique de longue date utilisée par une pénurie de sites bien établis. Ils ne nécessitent pas non plus d'appuyer sur la touche Maj et sont traités comme des limites de mots par pratiquement tout le monde.

— tpartee

2

Aussi loin que je me souvienne, les traits d'union ont été la norme la plus utilisée dans les URL et sont définitivement considérés comme les meilleures pratiques dans les normes d'aujourd'hui. Ne pas les utiliser parce que la sensation gênante me semble gênante.

— pistol-pete

2

Réponse courte:

mots en minuscule avec un trait d'union comme séparateur

Longue réponse:

À quoi sert une URL?

Si pointer vers une adresse est la réponse, alors une URL raccourcie fait également du bon travail. Si nous ne facilitons pas la lecture et la maintenance, cela n'aidera pas autant les développeurs que les mainteneurs. Ils représentent une entité sur le serveur, ils doivent donc être nommés logiquement.

Google recommande d'utiliser des tirets

Pensez à utiliser la ponctuation dans vos URL. L'URL http://www.example.com/green-dress.html nous est beaucoup plus utile que http://www.example.com/greendress.html . Nous vous recommandons d'utiliser des tirets (-) au lieu des traits de soulignement (_) dans vos URL.

Issu d'une formation en programmation, camelCase est un choix populaire pour nommer des mots communs.

Mais la RFC 3986 définit les URL comme sensibles à la casse pour différentes parties de l'URL. Étant donné que les URL sont sensibles à la casse, le garder discret (minuscule) est toujours sûr et considéré comme un bon standard. Maintenant, cela prend un étui à chameaux par la fenêtre.

Source: https://metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

— Trieur
source

-1

voici le meilleur des deux mondes.

J'aime aussi "souligne", outre tous vos points positifs à leur sujet, il y a aussi un certain style old-school.

Donc, ce que je fais, c'est utiliser des tirets bas et simplement ajouter une petite règle de réécriture au fichier .htaccess de votre Apache pour réécrire tous les tirets bas dans des tirets.

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

— user2597538
source