3. Alternatives à la spécification de structure dans les URI (Alternatives to Specifying Structure in URIs)

Compte tenu des problèmes décrits dans la section 1, la stratégie la plus réussie pour les applications et extensions qui souhaitent utiliser des URI est de les utiliser de la manière pour laquelle ils ont été conçus : comme des liens échangés dans le cadre du protocole, plutôt que comme une syntaxe spécifiée de manière statique. Plusieurs spécifications existantes peuvent aider dans ce domaine.

[RFC8288] spécifie les types de relations (relation types) pour les liens Web. En fournissant un cadre pour la liaison sur le Web, où chaque lien a un type de relation, un contexte et une cible, il permet aux applications de définir la sémantique et la connectivité d'un lien.

[RFC6570] fournit une syntaxe standard pour les modèles URI (URI Templates) qui peut être utilisée pour insérer dynamiquement des variables spécifiques à l'application dans un URI afin d'activer de telles applications tout en évitant d'empiéter sur le contrôle qu'en ont les propriétaires d'URI.

[RFC8615] permet de "réserver" des chemins spécifiques pour une utilisation standard sur les schémas URI qui optent pour ce mécanisme ("http" et "https" par défaut). Notez cependant que ce n'est pas une "soupape d'échappement" générale pour les applications qui ont besoin d'URI structurés ; consultez cette spécification pour plus d'informations.

Spécifier des structures plus élaborées dans une tentative d'éviter les collisions n'est pas une solution acceptable et ne résout pas les problèmes décrits dans la section 1. Par exemple, préfixer les paramètres de requête avec "myapp_" n'aide pas, car le préfixe lui-même est soumis au risque de collision (puisqu'il n'est pas "réservé").