De Wikipédia: Uniform Resource Locator
Un chemin d'accès , qui contient des données, généralement organisées sous forme hiérarchique , qui apparaît comme une séquence de segments séparés par des barres obliques.
Une requête facultative , séparée de la partie précédente par un point d'interrogation (?), Contenant une chaîne de requête de données non hiérarchiques .
- Selon la conception conceptuelle de l'URL, nous pouvons implémenter un PathParam pour les composants hiérarchiques de données / directives / localisateurs, ou implémenter un QueryParam lorsque les données ne sont pas hiérarchiques. Cela est logique car les chemins sont naturellement ordonnés, tandis que les requêtes contiennent des variables qui peuvent être ordonnées arbitrairement (paires variable / valeur non ordonnées).
Un commentateur précédent a écrit:
Je pense que si le paramètre identifie une entité spécifique, vous devez utiliser une variable de chemin.
Un autre a écrit:
Utilisez @PathParam pour la récupération en fonction de l'ID. L'utilisateur @QueryParam pour le filtre ou si vous avez une liste fixe d'options que l'utilisateur peut transmettre.
Un autre,
Je recommanderais de mettre tous les paramètres requis dans le chemin, et tous les paramètres facultatifs devraient certainement être des paramètres de chaîne de requête.
- Cependant, on pourrait mettre en œuvre un système flexible et non hiérarchique pour identifier des entités spécifiques! On peut avoir plusieurs index uniques sur une table SQL et permettre aux entités d'être identifiées à l'aide de n'importe quelle combinaison de champs qui composent un index unique! Différentes combinaisons (peut-être également ordonnées différemment) peuvent être utilisées pour les liens provenant de diverses entités liées (référents). Dans ce cas, nous pouvons avoir affaire à des données non hiérarchiques, utilisées pour identifier des entités individuelles - ou dans d'autres cas, ne spécifier que certaines variables / champs - certains composants d'index uniques - et récupérer une liste / un ensemble d'enregistrements. Dans de tels cas, il pourrait être plus facile, plus logique et raisonnable d'implémenter les URL en tant que QueryParams!
Une longue chaîne hexadécimale pourrait-elle diluer / diminuer la valeur des mots clés dans le reste du chemin? Cela pourrait valoir la peine considérer les implications SEO potentielles du placement de variables / valeurs dans le chemin ou dans la requêteet les implications pour l'interface humaine de savoir si nous voulons que les utilisateurs puissent parcourir / explorer la hiérarchie des URL en modifiant le contenu de la barre d'adresse. Ma page 404 Not Found utilise des variables SSI pour rediriger automatiquement les URL cassées vers leur parent! Les robots de recherche peuvent également parcourir la hiérarchie des chemins. D'un autre côté, personnellement, lorsque je partage des URL sur les réseaux sociaux, je supprime manuellement tous les identifiants uniques privés - généralement en tronquant la requête de l'URL, en ne laissant que le chemin d'accès: dans ce cas, il est utile de placer des identifiants uniques dans le chemin d'accès plutôt que dans la requête. Que nous voulions faciliter l'utilisation des composants de chemin d'accès en tant qu'interface utilisateur brute, cela dépend peut-être si les données / composants sont lisibles par l'homme ou non. La question de la lisibilité humaine se rattache quelque peu à la question de la hiérarchie: souvent, les données qui peuvent être exprimées sous forme de mots clés lisibles par l'homme sont également hiérarchiques; tandis que les données hiérarchiques peuvent souvent être exprimées sous forme de mots clés lisibles par l'homme. (Les moteurs de recherche eux-mêmes peuvent être définis comme augmentant l'utilisation des URL comme interface utilisateur.) Les hiérarchies de mots clés ou de directives peuvent ne pas être strictement ordonnées, mais elles sont généralement suffisamment proches pour que nous puissions couvrir d'autres cas dans le chemin, etétiqueter une option comme cas "canonique" .
Il existe fondamentalement plusieurs types de questions auxquelles nous pourrions répondre avec l'URL de chaque demande:
- Quel genre de document / chose demandons-nous / servons-nous?
- Quels sont ceux qui nous intéressent?
- Comment voulons-nous présenter les informations / enregistrements?
Q1 est presque certainement mieux couvert par le chemin ou par PathParams. Q3 (qui est probablement contrôlé via un ensemble de paramètres optionnels et de valeurs par défaut arbitrairement ordonnés); est presque certainement mieux couvert par QueryParams. Q2: Cela dépend…