|
Uniform Resource Identifier
Der Uniform Resource Identifier (kurz URI) dient zur Identifizierung einer abstrakten oder physischen Ressource. Im RFC 1630 wurde der Begriff durch Tim Berners-Lee eingeführt, wobei er den Begriff Universal Resource Identifier verwendete. Erst später in einem offiziellen W3C-Dokument wurde aus dem Universal ein Uniform. Man sollte sich deshalb nicht verwirren lassen, wenn insbesondere auch in Fachbüchern mal die eine, mal die andere Variante zu finden ist. Gemeint ist immer das selbe.
Die URI ist ein generischer Term für alle Kennzeichnungen, mit denen eine Ressource identifiziert werden kann. Eine URI kann also eine URL oder eine URN oder aber auch eine URC sein. Nachfolgend erfährt man mehr zur URI, aber auch zu URN, URL und URC.
Bevor wir zu URL, URN oder URC kommen, muss erst einmal geklärt werden, was überhaupt eine Resource ist, da diese jeweils in der Benennung URI, URN, URL und auch URC vorkommt. Eine Web-Ressource ist ein Objekt (abstrakt oder physisch), dass von einem MIME-Typ spezifiziert, von einem Webserver ausgeliefert und via standardisiertem Protokoll übertragen wird. Der Begriff "Resource" wird im RFC 3986 allerdings viel weiter aufgefasst. Danach wird der Begriff Resource für all das verwendet, das durch eine URI identifiziert werden kann. Im Vergleich zur Web-Ressource muss eine Ressource also nicht gezwungenermaßen über das Internet erreichbar sein.
Eine URI folgt einem bestimmten Aufbau, der im aktuellen Standard RFC 3968 festgeschrieben ist. Danach besteht die URI aus fünf Teilen: scheme (Schema oder Protokoll), authority (Anbieter oder Server), path (Pfad), query (Abfrage) und fragment (Teil), wovon nur scheme und path in jedem URI vorhanden sein müssen.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
Der Uniform Resource Name (kurz URN) ist wie oben schon angedeutet, eine URI. Die URN dient als dauerhafter, ortsunabhängiger Bezeichner für eine Ressource.
Der Aufbau baut auf dem der URIs auf, wobei das Schema urn ist. Nachfolgend der Aufbau: urn:<NID>:<NID-spezifischer Teil> . Eine Beispiels-URN wäre URN:ISBN:352770986X
Es ist wichtig, sich die Unterschiede zwischen den beiden URIs klar zu machen. URLs sind dafür gedachte, den Ort der Ressource, eindeutig zu beschreiben und sie somit zu lokalisieren. URNs hingegen geben der Ressource einen weltweit eindeutigen Namen, der sie über die gesamte Lebensdauer eindeutig identifiziert.
Gemäß dem RFC 1737 müssen URNs bestimmte Anforderungen erfüllen, die nachfolgend aufgeführt sind:
- Globaler Anwendungsbereich: Eine URN ist ein Namen mit einem globalen Anwendungsbereich, welcher kein Ort impliziert. Der Name gilt überall.
- Globale Einzigartigkeit: Die gleiche URN wird niemals zu zwei unterschiedlichen Ressourcen zugewiesen.
- Persistenz: Es ist gedacht, dass die Lebenszeit einer URN unendlich ist.
- Skalierbar: URN-Zuordnung zu jeder beliebigen Ressource.
- Altsystem-Support (Legacy Support): Schema muss existierende Legacy-Naming-Systems unterstützen.
- Erweiterbarkeit: Zukünftige Erweiterungen des Schemas müssen möglich sein
- Unabhängigkeit: Die Verantwortung, unter welche Bedingungen ein Name vergeben wird, liegt einzig und alleine bei der entsprechenden Autorität, die den Namen ausstellt
- Auflösung: URN behindert nicht die Auflösung -> Weitere Mechanismen werden benötigt
URNs können nicht so einfach wie URLs (z.B. über DNS) aufgelöst werden. Dies liegt in der Tatsache, dass URNs Ressourcen eindeutig benennen und nicht wie URLs beschreiben, wo sich die Ressource befindet. Ein etwas älterer Ansatz ist der sogenannte Resolver Discovery Service (kurz RDS). Diesem übergibt der Client die NID (namespace identifier) und bekommt vom RDS anschließend eine URN Resolver Adresse zurück. Anschließend kann er dem URN Resolver die NSS (namespace specific string) übergeben und bekommt anschließend eine URL oder URC zurück. Nun kann er ganz normal per GET die Ressource vom Resource Server anfordern. (siehe dazu auch den RFC 2276)
Aktuell schlägt die Internet Engineering Task Force für die Auflösung von URNs die Nutzung des Dynamic Delegation Discovery Systems (DDDS) vor. Mehr dazu findet man unter anderem in den RFCs 3401 bis 3405.
Der Uniform Resource Locator ist wohl die bekannteste URI. Sie identifiziert und lokalisiert eine Ressource, wie z.B. eine Website im Internet. Die Begriffe URI und URL werden oft (fälschlicherweise) synonym verwendet, da URLs die häufigste Art von URIs darstellen. Der aktuelle Stand ist als RFC 1738 publiziert.
Eine URL ist aus zwei Hauptbestandteilen aufgebaut:
<scheme>:<scheme-specific-part>
Die Schema-Bezeichnung am Anfang (scheme) legt dabei die Zugriffsmethode fest. Das könnte also: http, https, ftp, news, mailto, ... sein.
Der scheme-specific-part folgt anschließend folgender Syntax: //:<password>@<host>:<port>/<url-path>
Manche oder alle Teile von "<user>:<password>@", ":<password>", ":<port>", und "/<url-path>" können ausgelassen werden.
Nach RFC 1808 können URLs auch relativ sein. Diese relative URLs sind nur innerhalb eines Kontextes gültig. Eine absolute URL wäre beispielsweise: https://www.easy-network.de/uniform-resource-identifier.html die dazu gehörige relative URL würde einfach nur uniform-resource-identifier.html lauten.
Wie URL und URN ist auch URC ein URI. URC steht für Uniform Resource Characteristic und ist vergleichsweise unbekannt. Mehr zur URC findet man im RFC 1737, den wir schon von den URNs kennen.
Uniform Resource Characteristics (URCs) beinhalten zusätzliche Metainformation einer Ressource. Solche Metainformationen wären z.B. der Besitzer, Encoding, Zugriffrestriktionen oder auch Kosten.
Artikel veröffentlicht am 22.04.2014.
|
|
