Ligne 1, colonne 24
{/version,resource}- Variable:
version· Définie - Variable:
resource· Définie
Partie développée: /v1/search
URL / URI Tools
test de modèle URIcomprendre chaque partie produite
Saisissez un modèle et un objet JSON pour examiner l’URI et le résultat de chaque expression.
test de modèle URI
Les modèles et variables restent dans ce navigateur. Aucune adresse saisie ou produite n’est appelée.
Variables omises : Aucune
Clés JSON inutilisées : Aucune
Détail des expressions
Ligne 1, colonne 43
{?q,page,tags*}- Variable:
q· Définie - Variable:
page· Définie - Variable:
tags*· Définie
Partie développée: ?q=hello%20world&page=2&tags=red&tags=blue
2 expressions affichées sur 2
Syntaxe de développement
RFC 6570 niveau 4 : {var}, {+var}, {#var}, {.var}, {/var}, {;var}, {?var}, {&var}. :n limite le préfixe et * développe les listes ou les dictionnaires.
Limites en unités UTF-16 : modèle 16 384, JSON 65 536, résultat 262 144 ; au plus 500 expressions.
2 expressions · 0 variables omises · 75 unités en sortie
Un identifiant contenant une barre oblique ne se traite pas comme un chemin déjà structuré. Le test de modèle URI permet de vérifier cette distinction avec les valeurs réelles, avant qu’une mauvaise substitution ne change l’adresse utilisée par un client API.
La RFC 6570 détermine aussi comment une liste ou un dictionnaire devient une série de paramètres. Un modèle URI relatif est accepté : vous pouvez étudier une portion de chemin sans lui ajouter artificiellement un protocole ou un domaine.
Ce que révèle le test de modèle URI
Retrouver l’origine d’un paramètre absent
Le test de modèle URI affiche la position et le résultat de chaque expression. Si un paramètre disparaît, vérifiez sa variable : absente, null ou collection vide. Une chaîne vide possède un état distinct, car elle reste définie au sens du standard.
Comparer une liste groupée et développée
{?tags} produit une valeur regroupée avec des virgules. {?tags*} répète le nom tags pour chaque élément. Avec un dictionnaire, les clés des membres deviennent les noms des paramètres. Les détails montrent ces fragments sans devoir relire toute l’adresse.
Vérifier les clés, les formes et la mise à jour
01
Garder les noms exacts
user.id désigne une clé portant ce nom complet, pas un objet imbriqué. Les séquences encodées dans les noms ne sont pas décodées. Respectez également la casse entre le modèle et les variables JSON.
02
Choisir un exemple selon la question
L’exemple des caractères réservés conserve les barres obliques d’un chemin. Celui des valeurs composées montre listes, dictionnaires et préfixes Unicode. Le chargement passe par un aperçu ; après application, les anciennes entrées et leur résultat peuvent être restaurés une fois.
03
Exporter après une exécution actuelle
Le mode automatique attend 350 ms après une modification. Désactivez-le pour utiliser le bouton ou Ctrl/Cmd + Enter. Dès que les données changent, les anciens exports sont désactivés jusqu’à la réussite de la nouvelle expansion.
Des résultats dont on peut expliquer la structure
Les quatre niveaux de syntaxe
Le test de modèle URI traite l’expansion simple et les opérateurs +, #, ., /, ;, ? et &. :n retient de 1 à 9999 caractères Unicode ; * développe listes et dictionnaires. L’encodage pour cent et les séparateurs dépendent de l’opérateur choisi.
Les identifiants numériques restent exacts
Les nombres JSON sont conservés sous leur forme textuelle. Ainsi, 9007199254740993 n’est pas arrondi, et -0 ou une notation exponentielle ne sont pas réécrits. Les booléens deviennent true ou false, sans conversion des nombres en virgule flottante.
Des erreurs distinctes des omissions
Une erreur de syntaxe du modèle ou du JSON indique ligne et colonne. Les clés répétées sont rejetées ; les valeurs imbriquées sont identifiées par un JSON Pointer. Une variable non définie est signalée mais n’empêche pas une expansion valide, même si son fragment est vide.
Un rapport complet à conserver
La copie fournit seulement l’URI. Le rapport JSON contient le modèle, le texte JSON original, toutes les expressions et les noms omis ou inutilisés. L’affichage avance par groupes de 50 expressions, tandis que le téléchargement comprend toutes les entrées.
Formes acceptées et limites de traitement
- Un seul objet sans imbrication profonde
- La racine JSON doit être un objet. Ses valeurs peuvent être des chaînes, nombres, booléens, null, listes ou dictionnaires de scalaires. Les conteneurs imbriqués sont refusés, même inutilisés. Ni import de fichier ni traitement de plusieurs jeux de variables ne sont proposés.
- Une chaîne vide reste définie
- Les clés absentes, null et collections vides sont omises ; les membres null sont ignorés. Pour une chaîne vide, {?x} donne ?x= et {;x} donne ;x. Un modèle vide est autorisé si le JSON des variables est valide.
- Les noms ne sont pas interprétés comme des chemins
- La casse compte. Les points n’accèdent pas à des sous-objets et les noms encodés ne sont ni décodés ni normalisés. Une clé répétée provoque une erreur. L’ordre des membres du dictionnaire suit le texte JSON fourni.
- Pas de correction ultérieure de l’adresse
- L’expansion simple encode aussi le signe %. + et # conservent les séquences valides et les caractères réservés. Un espace littéral est invalide. Unicode est encodé en UTF-8 sans normalisation ; aucun protocole, hôte converti ou URL de base n’est ajouté.
- Des tailles finies, aucun résultat partiel exportable
- Les limites sont 16 384, 65 536 et 262 144 unités UTF-16 pour le modèle, le JSON et la sortie, avec 500 expressions. Le parseur commun limite la profondeur à 100, les nœuds à 50 000 et chaque nombre à 1 000 caractères. Une erreur bloque aussi l’export de l’ancien résultat.
- Une expansion à sens unique
- Il n’y a ni correspondance inverse avec des routes, ni vérification d’accès, import distant, valeurs par défaut ou exécution de code. Les séparateurs sont fixés par la RFC. Préparez une chaîne dans les variables si votre application exige un assemblage particulier.
Questions sur le test de modèle URI
Faut-il encoder les accolades d’un modèle URI en pourcentage ?
Conservez les accolades des expressions : /users/{id} contient une variable. /users/%7Bid%7D contient des accolades littérales encodées et n’est pas développé. Il ne faut pas encoder tout le modèle au préalable ; l’opérateur se charge de l’encodage des valeurs.
Dans la RFC 6570, en quoi l’opérateur / diffère-t-il des autres préfixes ?
/ ajoute une barre oblique devant chaque variable définie, et devant chaque élément d’une liste avec *. L’expansion simple encode les barres à l’intérieur des valeurs. + les conserve, mais n’en ajoute aucune. Ce sont des comportements différents.
La RFC 6570 permet-elle de séparer des paramètres facultatifs par des espaces ?
Aucun opérateur ne permet un séparateur facultatif arbitraire. Préparez une chaîne contenant les mots souhaités ; ses espaces deviendront %20. Une liste avec * utilise toujours le séparateur prévu par son opérateur, par exemple / ou &.
Peut-on valider un modèle URI RFC 6570 avec une expression régulière ?
Une expression régulière seule ne vérifie pas les types des variables. {items:3} peut être syntaxiquement correct mais reste interdit si items est une liste. Cet outil vérifie conjointement les expressions et les variables, puis indique la position d’un échec.
Les modèles URI permettent-ils de faire correspondre des URI à des routes ?
La RFC 6570 définit le développement des variables en URI. L’opération inverse peut être ambiguë avec plusieurs variables, des caractères réservés ou des dictionnaires développés. Cette page n’extrait donc pas de paramètres de route depuis une URI.
Un problème ?
Lancer un test de modèle URI concret
Comparez vos valeurs aux exemples de chemin ou de requête, puis conservez le rapport du résultat actuel.
Un modèle, un objet de variables, des fragments vérifiables.