2. Best Current Practices für die Standardisierung strukturierter URIs (Best Current Practices for Standardizing Structured URIs)

Dieser Abschnitt aktualisiert [RFC3986], indem er Spezifikationen berät, wie sie Struktur und Semantik innerhalb von URIs definieren sollten. Best Practices unterscheiden sich je nach betroffener URI-Komponente, wie unten beschrieben.

2.1. URI-Schemas (URI Schemes)

Anwendungen und Erweiterungen können (MAY) die Verwendung eines oder mehrerer spezifischer URI-Schemas erfordern; beispielsweise ist es vollkommen akzeptabel zu verlangen, dass eine Anwendung "http"- und "https"-URIs unterstützt. Anwendungen sollten jedoch (ought not) die Verwendung anderer URI-Schemas in der Zukunft ausschließen, es sei denn, sie sind eindeutig nur mit den nominierten Schemas verwendbar.

Eine Spezifikation, die eine Unterstruktur für URI-Schemas insgesamt definiert (z. B. ein Präfix oder Suffix für URI-Schemanamen), muss (MUST) dies durch Änderung von [BCP35] tun (ein außergewöhnlicher Umstand).

2.2. URI-Autoritäten (URI Authorities)

Schemadefinitionen definieren das Vorhandensein, Format und die Semantik einer Autoritätskomponente in URIs; alle anderen Spezifikationen dürfen nicht (MUST NOT) die Struktur oder Semantik für URI-Autoritäten einschränken oder definieren, es sei denn, sie aktualisieren die Schemaregistrierung selbst oder die Strukturen, auf denen sie beruht (z. B. DNS-Namenssyntax, wie in Abschnitt 3.5 von [RFC1034] definiert).

Beispielsweise kann eine Erweiterung oder Anwendung nicht sagen, dass das Präfix "foo" in "https://foo_app.example.com" bedeutungsvoll ist oder eine spezielle Behandlung in URIs auslöst, es sei denn, sie aktualisieren entweder das "http"-URI-Schema oder die DNS-Hostname-Syntax.

Anwendungen können (MAY) den von ihnen verwendeten Port benennen oder einschränken, falls zutreffend. Beispielsweise könnte BarApp über Port nnnn laufen (vorausgesetzt, er ist ordnungsgemäß registriert).

2.3. URI-Pfade (URI Paths)

Schemadefinitionen definieren das Vorhandensein, Format und die Semantik einer Pfadkomponente in URIs, obwohl diese oft an die Anwendung(en) in einer bestimmten Bereitstellung delegiert werden.

Um Kollisionen, Starrheit und fehlerhafte Client-Annahmen zu vermeiden, dürfen Spezifikationen kein (MUST NOT) festes Präfix für ihre URI-Pfade definieren -- beispielsweise "/myapp" -- es sei denn, dies ist durch die Schemadefinition erlaubt.

Eine Ausnahme von dieser Anforderung sind registrierte "bekannte (well-known)" URIs, wie in [RFC8615] spezifiziert. Siehe dieses Dokument für eine Beschreibung der Anwendbarkeit dieses Mechanismus.

Beachten Sie, dass dies nicht für Anwendungen gilt, die eine Struktur des Pfads eines URI "unter" einer vom Server kontrollierten Ressource definieren. Da das Präfix unter der Kontrolle der Partei steht, die die Anwendung bereitstellt, werden Kollisionen und Starrheit vermieden, und das Risiko fehlerhafter Client-Annahmen wird reduziert.

Beispielsweise könnte eine Anwendung "app_root" als ein durch die Bereitstellung kontrolliertes URI-Präfix definieren. Von der Anwendung definierte Ressourcen könnten dann als vorhanden bei "{app_root}/foo" und "{app_root}/bar" angenommen werden.

Erweiterungen dürfen nicht (MUST NOT) eine Struktur innerhalb einzelner URI-Komponenten definieren (z. B. ein Präfix oder Suffix), wiederum um Kollisionen und fehlerhafte Client-Annahmen zu vermeiden.

2.4. URI-Abfragen (URI Queries)

Das Vorhandensein, Format und die Semantik der Abfragekomponente von URIs hängen von vielen Faktoren ab und können durch eine Schemadefinition eingeschränkt werden. Oft werden sie durch die Implementierung einer Ressource selbst bestimmt.

Anwendungen können (MAY) die Syntax von Abfragen für die Ressourcen unter ihrer Kontrolle spezifizieren. Dies kann jedoch zu betrieblichen Schwierigkeiten für Bereitstellungen führen, die eine bestimmte Form einer Abfrage nicht unterstützen. Beispielsweise möchte eine Website möglicherweise eine Anwendung mit "statischen" Dateien unterstützen, die keine Abfrageparameter unterstützen.

Erweiterungen dürfen nicht (MUST NOT) das Format oder die Semantik von Abfragen einschränken, um Kollisionen und fehlerhafte Client-Annahmen zu vermeiden. Beispielsweise würde eine Erweiterung, die angibt, dass alle Abfrageparameter mit dem Namen "sig" eine kryptografische Signatur anzeigen, mit potenziell bereits existierenden Abfrageparametern auf Websites kollidieren und Clients dazu bringen, anzunehmen, dass jeder übereinstimmende Abfrageparameter eine Signatur ist.

Gemäß dem Abschnitt "Formularübermittlung (Form submission)" von [HTML5] schränkt HTML die Syntax von Abfragezeichenfolgen ein, die bei der Formularübermittlung verwendet werden. Neue Formularsprachen werden ermutigt, die Erstellung einer breiteren Vielfalt von URIs zu ermöglichen (z. B. indem das Formular neue Pfadkomponenten erstellen kann usw.).

2.5. URI-Fragment-Identifikatoren (URI Fragment Identifiers)

Abschnitt 3.5 von [RFC3986] spezifiziert die Syntax und Semantik von Fragment-Identifikatoren als abhängig vom Medientyp einer potenziell abgerufenen Ressource. Daher dürfen andere Spezifikationen keine (MUST NOT) Struktur innerhalb des Fragment-Identifikators definieren, es sei denn, sie definieren explizit eine zur Wiederverwendung durch Medientypen in ihren Definitionen (z. B. wie JSON Pointer [RFC6901] es tut).

Eine Anwendung, die gemeinsame Fragment-Identifikatoren über nicht von ihr kontrollierte Medientypen hinweg definiert, würde Interoperabilitätsprobleme mit Handlern für diese Medientypen erzeugen (da die neue, nicht standardmäßige Syntax nicht erwartet wird).