Zum Hauptinhalt springen

2. Links

In dieser Spezifikation ist ein Link eine typisierte Verbindung zwischen zwei Ressourcen, bestehend aus:

  • einem Link-Kontext (link context)
  • einem Link-Relationstyp (link relation type) (Abschnitt 2.1)
  • einem Link-Ziel (link target)
  • optionalen Zielattributen (target attributes) (Abschnitt 2.2)

Ein Link kann als Aussage der folgenden Form betrachtet werden: „Der Link-Kontext hat eine Ressource vom Link-Relationstyp am Link-Ziel, die die Zielattribute aufweist."

Zum Beispiel: „https://www.example.com/" hat eine „canonical"-Ressource unter „https://example.com", die den „type" „text/html" hat.

Sowohl Link-Kontext als auch Link-Ziel sind Internationalized Resource Identifiers (IRIs) [RFC3987]. Im häufigen Fall wird der Link-Kontext jedoch auch ein URI [RFC3986] sein, da viele Protokolle (wie HTTP) das Dereferenzieren von IRIs nicht unterstützen. Ebenso werden Link-Ziele manchmal in Serialisierungen, die keine IRIs unterstützen (z. B. das in Abschnitt 3 definierte Link-Headerfeld), in URIs umgewandelt (siehe [RFC3987] Abschnitt 3.1).

Diese Spezifikation legt keine Einschränkungen für die Kardinalität von Links fest; es kann mehrere Links zu einem bestimmten Ziel und von einem bestimmten Ziel geben, sowie mehrere Links desselben oder unterschiedlicher Typen zwischen einem gegebenen Kontext und Ziel. Ebenso ist die relative Reihenfolge von Links in einer bestimmten Serialisierung oder zwischen Serialisierungen (z. B. Link-Headerfeld und Links im Inhalt) in dieser Spezifikation nicht festgelegt oder bedeutsam; Anwendungen, die die Reihenfolge berücksichtigen möchten, können dies tun.

Links werden in Link-Serialisierungen übermittelt; sie sind „Bytes auf der Leitung" und können in verschiedenen Formen erscheinen. Zum Beispiel definieren sowohl Atom [RFC4287] als auch HTML [W3C.REC-html5-20141028] Möglichkeiten, Links in ihre jeweiligen Formate zu serialisieren, und Abschnitt 3 definiert, wie Links in HTTP-Headerfeldern serialisiert werden.

Diese Spezifikation definiert keine gemeinsame Syntax für Links über verschiedene Serialisierungen hinweg und schreibt keinen bestimmten Kontext für einen gegebenen Link vor; es wird erwartet, dass die Serialisierung von Links beide Aspekte spezifiziert.

Schließlich werden Links von Link-Anwendungen verwendet. Typischerweise definiert eine Anwendung die von ihr verwendeten Link-Relationstypen sowie die Serialisierungen, in denen sie erscheinen können. Zum Beispiel sucht die Anwendung „Web-Browsing" nach dem „stylesheet"-Link-Relationstyp in HTML-Link-Serialisierungen (und optional im Link-Headerfeld), während die Anwendung „AtomPub" die Link-Relationen „edit" und „edit-media" in Atom-Serialisierungen verwendet.

Im einfachsten Fall identifiziert ein Link-Relationstyp die Semantik eines Links. Zum Beispiel zeigt ein Link mit dem Relationstyp „copyright" an, dass der aktuelle Link-Kontext eine Copyright-Ressource am Link-Ziel hat.

Link-Relationstypen können auch verwendet werden, um anzuzeigen, dass die Zielressource bestimmte Eigenschaften hat oder ein bestimmtes Verhalten zeigt; zum Beispiel impliziert ein „service"-Link, dass das Link-Ziel als Teil eines definierten Protokolls verwendet werden kann (in diesem Fall eine Dienstbeschreibung).

Relationstypen SOLLTEN NICHT mit Medientypen [RFC2046] verwechselt werden; sie identifizieren nicht das Format der Darstellung, die beim Dereferenzieren des Links entsteht. Stattdessen beschreiben sie nur, wie der aktuelle Kontext mit einer anderen Ressource in Beziehung steht.

Relationstypen SOLLTEN NICHT auf der Grundlage des Vorhandenseins oder Nichtvorhandenseins eines anderen Link-Relationstyps oder der Kardinalität seines eigenen Auftretens zusätzliche Semantik ableiten. Eine Ausnahme bildet die Kombination der registrierten Relationstypen „alternate" und „stylesheet", die aus historischen Gründen in HTML eine besondere Bedeutung hat.

Es gibt zwei Arten von Relationstypen: registrierte und erweiterte.

2.1.1. Registered Relation Types (Registrierte Relationstypen)​

Klar definierte Relationstypen können als Token registriert werden, um ihre Wiederverwendung durch andere Anwendungen zu erleichtern und/oder zu fördern, unter Verwendung des Verfahrens in Abschnitt 2.1.1.1.

Registrierte Relationstyp-Namen MÜSSEN der reg-rel-type-Regel entsprechen (siehe Abschnitt 3.3) und MÜSSEN zeichenweise ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden. Sie SOLLTEN für die Spezifität des Relationstyps geeignet sein; das heißt, wenn die Semantik für eine bestimmte Anwendung sehr spezifisch ist, SOLLTE der Name dies widerspiegeln, damit allgemeinere Namen für weniger spezifische Verwendungen verfügbar sind.

Registrierte Relationstypen DÜRFEN NICHT den Medientyp des Link-Kontexts einschränken und DÜRFEN NICHT die verfügbaren Darstellungsmedientypen des Link-Ziels einschränken. Sie können jedoch das Verhalten und die Eigenschaften der Zielressource spezifizieren (z. B. erlaubte HTTP-Methoden sowie erforderliche Anfrage- und Antwortmedientypen).

2.1.2. Extension Relation Types (Erweiterungs-Relationstypen)​

Anwendungen, die keinen Relationstyp registrieren möchten, können Erweiterungs-Relationstypen verwenden, die URIs [RFC3986] sind, die den Relationstyp eindeutig identifizieren. Obwohl der URI auf eine Ressource verweisen kann, die eine Definition der Semantik des Relationstyps enthält, SOLLTEN Clients diese Ressource nicht automatisch abrufen, um ihre Server nicht zu belasten.

Der für einen Erweiterungs-Relationstyp verwendete URI SOLLTE unter der Kontrolle der Person oder Partei stehen, die ihn definiert, oder an diese delegiert sein.

Beim Vergleich von Erweiterungs-Relationstypen MÜSSEN diese als Zeichenketten (nach Umwandlung in URIs, wenn sie in einem anderen Format serialisiert sind) zeichenweise ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden. Daher SOLLTEN vollständig kleingeschriebene URIs für Erweiterungsrelationen verwendet werden.

Beachten Sie, dass Erweiterungs-Relationstypen zwar URIs sein müssen, die Serialisierung von Links sie jedoch in einer anderen Form darstellen kann, solange sie in URIs umgewandelt werden können.

2.2. Target Attributes (Zielattribute)​

Zielattribute sind eine Liste von Schlüssel/Wert-Paaren, die den Link oder sein Ziel beschreiben; zum Beispiel Medientyp-Hinweise.

Sie können von einzelnen Link-Relationstypen und Link-Serialisierungen definiert werden.

Diese Spezifikation versucht nicht, die Namen von Zielattributen, ihre Kardinalität oder Verwendung zu koordinieren. Personen, die Serialisierungen erstellen und pflegen, SOLLTEN ihre Zielattribute koordinieren, um semantische oder syntaktische Konflikte zu vermeiden, und KÖNNEN ihre eigenen Zielattribut-Registrierungen definieren.

Namen von Zielattributen SOLLTEN der token-Regel entsprechen, SOLLTEN ABER NICHT auf ASCII beschränkt sein; sie SOLLTEN ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden.

Letztes Update am