2. Meilleures pratiques actuelles pour la standardisation des URI structurés (Best Current Practices for Standardizing Structured URIs)
Cette section met à jour [RFC3986] en conseillant comment les spécifications devraient définir la structure et la sémantique au sein des URI. Les meilleures pratiques diffèrent selon le composant URI en question, comme décrit ci-dessous.
2.1. Schémas URI (URI Schemes)
Les applications et extensions peuvent (MAY) exiger l'utilisation d'un ou plusieurs schémas URI spécifiques ; par exemple, il est parfaitement acceptable d'exiger qu'une application prenne en charge les URI "http" et "https". Cependant, les applications ne devraient pas (ought not) exclure l'utilisation d'autres schémas URI à l'avenir, à moins qu'ils ne soient clairement utilisables uniquement avec les schémas désignés.
Une spécification qui définit une sous-structure pour les schémas URI dans leur ensemble (par exemple, un préfixe ou un suffixe pour les noms de schémas URI) doit (MUST) le faire en modifiant [BCP35] (une circonstance exceptionnelle).
2.2. Autorités URI (URI Authorities)
Les définitions de schémas définissent la présence, le format et la sémantique d'un composant autorité dans les URI ; toutes les autres spécifications ne doivent pas (MUST NOT) contraindre ou définir la structure ou la sémantique des autorités URI, à moins qu'elles ne mettent à jour l'enregistrement du schéma lui-même ou les structures sur lesquelles il repose (par exemple, la syntaxe des noms DNS, telle que définie dans la section 3.5 de [RFC1034]).
Par exemple, une extension ou une application ne peut pas dire que le préfixe "foo" dans "https://foo_app.example.com" est significatif ou déclenche un traitement spécial dans les URI, à moins qu'elle ne mette à jour soit le schéma URI "http", soit la syntaxe des noms d'hôte DNS.
Les applications peuvent (MAY) désigner ou contraindre le port qu'elles utilisent, le cas échéant. Par exemple, BarApp pourrait fonctionner sur le port nnnn (à condition qu'il soit correctement enregistré).
2.3. Chemins URI (URI Paths)
Les définitions de schémas définissent la présence, le format et la sémantique d'un composant chemin dans les URI, bien que ceux-ci soient souvent délégués aux applications dans un déploiement donné.
Pour éviter les collisions, la rigidité et les hypothèses erronées des clients, les spécifications ne doivent pas (MUST NOT) définir un préfixe fixe pour leurs chemins URI -- par exemple, "/myapp" -- à moins que la définition du schéma ne le permette.
Une exception à cette exigence concerne les URI "bien connus (well-known)" enregistrés, tels que spécifiés par [RFC8615]. Consultez ce document pour une description de l'applicabilité de ce mécanisme.
Notez que cela ne s'applique pas aux applications définissant une structure du chemin d'un URI "sous" une ressource contrôlée par le serveur. Étant donné que le préfixe est sous le contrôle de la partie déployant l'application, les collisions et la rigidité sont évitées, et le risque d'hypothèses erronées des clients est réduit.
Par exemple, une application peut définir "app_root" comme préfixe URI contrôlé par le déploiement. Les ressources définies par l'application peuvent alors être supposées présentes à "{app_root}/foo" et "{app_root}/bar".
Les extensions ne doivent pas (MUST NOT) définir une structure au sein de composants URI individuels (par exemple, un préfixe ou un suffixe), encore une fois pour éviter les collisions et les hypothèses erronées des clients.
2.4. Requêtes URI (URI Queries)
La présence, le format et la sémantique du composant requête des URI dépendent de nombreux facteurs et peuvent être contraints par une définition de schéma. Souvent, ils sont déterminés par l'implémentation d'une ressource elle-même.
Les applications peuvent (MAY) spécifier la syntaxe des requêtes pour les ressources sous leur contrôle. Cependant, cela peut causer des difficultés opérationnelles pour les déploiements qui ne prennent pas en charge une forme particulière de requête. Par exemple, un site peut souhaiter prendre en charge une application en utilisant des fichiers "statiques" qui ne prennent pas en charge les paramètres de requête.
Les extensions ne doivent pas (MUST NOT) contraindre le format ou la sémantique des requêtes, pour éviter les collisions et les hypothèses erronées des clients. Par exemple, une extension qui indique que tous les paramètres de requête portant le nom "sig" indiquent une signature cryptographique entrerait en collision avec des paramètres de requête potentiellement préexistants sur les sites et amènerait les clients à supposer que tout paramètre de requête correspondant est une signature.
Selon la section "Soumission de formulaire (Form submission)" de [HTML5], HTML contraint la syntaxe des chaînes de requête utilisées dans la soumission de formulaires. Les nouveaux langages de formulaires sont encouragés à permettre la création d'une plus grande variété d'URI (par exemple, en permettant au formulaire de créer de nouveaux composants de chemin, etc.).
2.5. Identificateurs de fragment URI (URI Fragment Identifiers)
La section 3.5 de [RFC3986] spécifie que la syntaxe et la sémantique des identificateurs de fragment dépendent du type de média d'une ressource potentiellement récupérée. Par conséquent, les autres spécifications ne doivent pas (MUST NOT) définir de structure dans l'identificateur de fragment, à moins qu'elles n'en définissent explicitement une pour réutilisation par les types de média dans leurs définitions (par exemple, comme le fait JSON Pointer [RFC6901]).
Une application qui définit des identificateurs de fragment communs sur des types de média qu'elle ne contrôle pas engendrerait des problèmes d'interopérabilité avec les gestionnaires de ces types de média (car la nouvelle syntaxe non standard n'est pas attendue).