3. Alternativen zur Spezifikation von Struktur in URIs (Alternatives to Specifying Structure in URIs)

Angesichts der in Abschnitt 1 beschriebenen Probleme ist die erfolgreichste Strategie für Anwendungen und Erweiterungen, die URIs verwenden möchten, sie in der Weise zu verwenden, für die sie konzipiert wurden: als Links, die als Teil des Protokolls ausgetauscht werden, anstatt als statisch spezifizierte Syntax. Mehrere bestehende Spezifikationen können dabei helfen.

[RFC8288] spezifiziert Relationstypen (Relation Types) für Web-Links. Durch die Bereitstellung eines Frameworks für die Verlinkung im Web, bei dem jeder Link einen Relationstyp, Kontext und Ziel hat, ermöglicht es Anwendungen, die Semantik und Konnektivität eines Links zu definieren.

[RFC6570] bietet eine Standardsyntax für URI-Templates (URI Templates), die verwendet werden kann, um anwendungsspezifische Variablen dynamisch in einen URI einzufügen, um solche Anwendungen zu ermöglichen, während gleichzeitig vermieden wird, die Kontrolle der URI-Eigentümer darüber zu beeinträchtigen.

[RFC8615] erlaubt es, bestimmte Pfade für die Standardverwendung auf URI-Schemas zu "reservieren", die sich für diesen Mechanismus entscheiden ("http" und "https" standardmäßig). Beachten Sie jedoch, dass dies kein allgemeines "Fluchtventil" für Anwendungen ist, die strukturierte URIs benötigen; siehe diese Spezifikation für weitere Informationen.

Die Spezifikation aufwändigerer Strukturen in dem Versuch, Kollisionen zu vermeiden, ist keine akzeptable Lösung und adressiert nicht die in Abschnitt 1 beschriebenen Probleme. Beispielsweise hilft das Voranstellen von Abfrageparametern mit "myapp_" nicht, da das Präfix selbst dem Risiko einer Kollision ausgesetzt ist (da es nicht "reserviert" ist).