Autor — Sir Tim Berners-Lee, Erfinder von URI, URL, HTTP, HTML und dem World Wide Web, gegenwärtiger Direktor des W3C. Der Artikel wurde 1998 geschrieben.

Welchen URI kann man als „cool“ betrachten?
Einen, der sich nicht ändert.
Wie ändern sich URIs?
URIs ändern sich nicht: Sie werden von Menschen geändert.

Theoretisch haben Menschen keinen Grund, URIs zu ändern (oder die Dokumente nicht mehr zu unterstützen), aber in der Praxis gibt es Millionen.

Theoretisch besitzt der nominale Inhaber des Domainnamens tatsächlich den Namensraum der Domain und damit alle URIs darin. Abgesehen von Insolvenz gibt es nichts, was den Domaininhaber daran hindert, den Namen zu behalten. Und theoretisch steht der URI-Raum unter Ihrem Domainnamen vollständig unter Ihrem Kontrolle, sodass Sie ihn so stabil machen können, wie Sie möchten. In gewissem Maße ist der einzige triftige Grund für das Verschwinden eines Dokuments aus dem Internet, dass das Unternehmen, dem der Domainname gehörte, in Konkurs gegangen ist oder sich nicht mehr leisten kann, den Server zu betreiben. Warum gibt es also so viele tote Links in der Welt? Teilweise ist es einfach ein Mangel an Voraussicht. Hier sind einige Gründe, die man hören könnte:

Wir haben die Website einfach umstrukturiert, um sie besser zu machen.

Glauben Sie wirklich, dass alte URIs nicht mehr funktionieren können? Wenn ja, haben Sie sie sehr schlecht ausgewählt. Denken Sie daran, dass die neuen nach dem nächsten Redesign erhalten bleiben.

Wir haben so viel Material, dass wir nicht nachverfolgen können, was veraltet, vertraulich oder noch aktuell ist, und deshalb haben wir gedacht, es wäre besser, einfach alles abzuschalten.

Ich kann Ihnen nur mein Beileid aussprechen. Das W3C hatte eine Phase, in der wir archivierte Materialien sorgfältig auf Datenschutz überprüfen mussten, bevor wir sie öffentlich zugänglich machten. Die Entscheidung sollte im Voraus gut durchdacht werden – stellen Sie sicher, dass Sie mit jedem Dokument einen akzeptablen Leserkreis, das Erstellungsdatum und idealerweise das Ablaufdatum festhalten. Bewahren Sie diese Metadaten auf.

Nun, wir haben festgestellt, dass wir die Dateien verschieben müssen…

Das ist eine der erbärmlichsten Ausreden. Viele wissen nicht, dass Webserver Ihnen ermöglichen, die Beziehung zwischen der URI eines Objekts und dessen tatsächlichem Standort im Dateisystem zu verwalten. Stellen Sie sich den URI-Raum als einen abstrakten Raum vor, der perfekt organisiert ist. Dann machen Sie eine Zuordnung zu jeder Realität, die Sie tatsächlich zur Umsetzung verwenden. Informieren Sie dann den Webserver darüber. Sie können sogar einen Teil Ihres Servers schreiben, um alles richtig zu machen.

John unterstützt diese Datei nicht mehr, jetzt macht das Jane.

War Johns Name in der URI? Nein, die Datei lag einfach in seinem Verzeichnis? Verstehe.

Früher haben wir dafür CGI-Skripte verwendet, jetzt nutzen wir ein binäres Programm.

Es gibt die verrückte Idee, dass Seiten, die von Skripten erstellt werden, im Bereich "cgibin" oder "cgi" liegen sollten. Das enthüllt, wie Sie Ihren Webserver starten. Ändern Sie die Mechanik (auch wenn Sie den Inhalt beibehalten), und ups — alle Ihre URIs ändern sich.

Nehmen wir zum Beispiel die National Science Foundation (NSF):

Online-Dokumente der NSF

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Die erste Seite zum Starten des Dokumentenansichts wird eindeutig in ein paar Jahren nicht mehr so bleiben. cgi-bin, oldbrowse und pl — all dies gibt Teile von Informationen darüber, wie-wir-es-jetzt-machen. Wenn Sie jedoch eine Seite zur Suche nach einem Dokument verwenden, erhalten Sie als erstes gleich ein schlechtes Ergebnis:

Bericht der Arbeitsgruppe für Kryptologie und Codierungstheorie

http://www.nsf.gov/cgi-bin/getpub?nsf9814

für die Indexseite des Dokuments, obwohl das eigentliche HTML-Dokument viel besser aussieht:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Hier gibt der Titel pubs/1998 jedem zukünftigen Archivdienst einen guten Schlüssel zum Verständnis, dass das alte Klassifizierungsschema von 1998 noch funktioniert. Obwohl die Dokumentnummern im Jahr 2098 vielleicht anders aussehen, kann ich mir vorstellen, dass diese URI weiterhin gültig sein wird, und sie wird NSF oder einer anderen Organisation, die das Archiv unterstützen wird, nicht im Wege stehen.

Ich dachte nicht, dass URLs konstant sein müssen – es gab doch URNs.

Wahrscheinlich ist das einer der schlimmsten Nebeneffekte der Diskussion über URNs. Einige denken, dass sie aufgrund von Ermittlungen zu einem beständigeren Namensraum lässig mit toten Links umgehen können, weil „URN das alles beheben wird“. Wenn Sie einer dieser Menschen sind, lassen Sie sich enttäuschen.

Die meisten URN-Schemata, die ich gesehen habe, ähneln einer Autoritätskennung, gefolgt entweder von einem Datum und einem von Ihnen gewählten String oder einfach nur von einem String, den Sie auswählen. Das sieht sehr ähnlich aus wie ein HTTP-URI. Mit anderen Worten, wenn Sie denken, dass Ihre Organisation in der Lage sein wird, langlebige URNs zu erstellen, beweisen Sie es jetzt, indem Sie sie für Ihre HTTP-URIs verwenden. Im HTTP selbst gibt es nichts, was Ihren URI instabil macht. Nur Ihre Organisation. Erstellen Sie eine Datenbank, die die URN des Dokuments mit dem aktuellen Dateinamen abgleicht, und lassen Sie den Webserver diese zur tatsächlichen Dateiabrufung verwenden.

Wenn Sie bis zu diesem Punkt gekommen sind und Sie keine Zeit, kein Geld und keine Kontakte haben, um irgendeine Software zu entwickeln, können Sie folgende Entschuldigung anführen:

Wir wollten, hatten aber einfach nicht die nötigen Werkzeuge.

Darüber kann man Mitleid haben. Ich stimme vollkommen zu. Was Sie tun müssen, ist, den Webserver dazu zu bringen, sofort einen stabilen URI zu verarbeiten und die Datei zurückzugeben, wo auch immer sie momentan in Ihrem verrückten Dateisystem gespeichert ist. Sie möchten alle URIs in einer Datei als Überprüfung speichern und die Datenbank ständig aktuell halten. Sie möchten die Beziehungen zwischen verschiedenen Versionen und Übersetzungen desselben Dokuments beibehalten und auch einen unabhängigen Prüfzähler speichern, um vor Dateibeschädigungen durch zufällige Fehler zu schützen. Und Webserver kommen einfach nicht mit diesen Funktionen aus der Box. Wenn Sie ein neues Dokument erstellen möchten, fordert Ihr Editor auf, einen URI festzulegen.

Sie benötigen die Möglichkeit, das Eigentum, den Dokumentenzugriff, das Sicherheitsniveau auf Archivniveau und mehr im URI-Raum zu ändern, ohne den URI zu ändern.

Es ist wirklich schlecht. Aber wir werden das beheben. Im W3C verwenden wir die Funktionalität von Jigedit (Jigsaw-Server zur Bearbeitung), die Versionen verfolgt, und experimentieren mit Dokumentenerstellungs-Skripten. Wenn Sie Werkzeuge, Server und Clients entwickeln, achten Sie auf dieses Problem!

Diese Entschuldigung gilt auch für viele W3C-Seiten, einschließlich dieser: Also tun Sie das, was ich sage, und nicht das, was ich tue.

Warum sollte mich das interessieren?

Wenn Sie die URI auf Ihrem Server ändern, können Sie nie ganz sicher sein, wer auf die alte URI verlinken wird. Es könnten Links von normalen Webseiten sein. Lesezeichen auf Ihre Seite. Die URI könnte in den Margen eines Briefes an einen Freund kritzeln.

Wenn jemand auf einen Link klickt und dieser defekt ist, verliert er normalerweise das Vertrauen in den Serverbesitzer. Zudem ist er frustriert – sowohl emotional als auch tatsächlich, da er sein Ziel nicht erreichen kann.

Viele Menschen beschweren sich ständig über defekte Links, und ich hoffe, der Schaden ist offensichtlich. Ich hoffe, der reputationsschädigende Effekt für den Serveradministrator, wo das Dokument verschwunden ist, ist ebenso klar.

Was soll ich also tun? URI-Design.

Es ist die Pflicht des Website-Betreibers, URIs zu erstellen, die auch in 2 Jahren, in 20 Jahren und sogar in 200 Jahren verwendet werden können. Dazu sind Bedacht, Organisation und Zielstrebigkeit erforderlich.

URIs ändern sich, wenn sich irgendwelche Informationen darin ändern. Es ist sehr wichtig, wie Sie sie gestalten. (Was, URI-Design? Muss ich URIs entwerfen? Ja, darüber sollten Sie nachdenken). Design bedeutet hauptsächlich, dass in der URI keine Informationen enthalten sein sollten.

Das Erstellungsdatum des Dokuments – das Datum, an dem die URI ausgegeben wurde – ist etwas, das sich niemals ändern wird. Es ist sehr hilfreich, um Anfragen zu trennen, die das neue System verwenden, von denen, die das alte System nutzen. Es ist ein guter Ausgangspunkt für die URI. Wenn auf dem Dokument ein Datum angegeben ist, selbst wenn das Dokument in Zukunft relevant sein wird, ist es ein guter Anfang.

Die einzige Ausnahme ist eine Seite, die absichtlich die "letzte" Version ist, zum Beispiel für die gesamte Organisation oder einen großen Teil davon.

http://www.pathfinder.com/money/moneydaily/latest/

Dies ist die letzte Kolumne von Money Daily in der Zeitschrift Money. Der Hauptgrund, warum in dieser URI kein Datum benötigt wird, besteht darin, dass es keinen Grund gibt, die URI zu speichern, die länger als die Zeitschrift bestehen wird. Das Konzept von Money Daily wird verschwinden, wenn Money verschwindet. Wenn Sie auf Inhalte verweisen möchten, sollten Sie separat in Archiven darauf verweisen:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Sieht gut aus. Geht davon aus, dass "money" im gesamten Verlauf von pathfinder.com dasselbe bedeuten wird. Es gibt eine Dopplung von "98" und den unnötigen ".html", aber ansonsten sieht es nach einer starken URI aus.

Was beiseite lassen?

Alles! Abgesehen vom Erstellungsdatum, indem Sie irgendwelche Informationen in die URI einfügen, bitten Sie in irgendeiner Weise um Probleme.

• Name des Autors. Die Urheberschaft kann sich mit neuen Versionen ändern. Menschen verlassen Organisationen und übergeben Dinge an andere.
• Gegenstand. Es ist sehr kompliziert. Es sieht immer anfangs gut aus, aber ändert sich erstaunlich schnell. Ich werde das weiter unten näher erläutern.
• Status. Kataloge wie „alt“, „Entwurf“ usw., ganz zu schweigen von „letzte“ und „toll“, erscheinen in allen Dateisystemen. Dokumente ändern den Status - sonst hätte es keinen Sinn, Entwürfe zu erstellen. Die letzte Version eines Dokuments benötigt eine konstante ID, unabhängig von ihrem Status. Halten Sie den Status vom Namen fern.
• Zugang. Im W3C haben wir die Website in Bereiche für Mitarbeiter, Mitglieder und die Öffentlichkeit unterteilt. Das klingt gut, aber natürlich beginnen Dokumente als Teamideen von Mitarbeitern, werden mit Mitgliedern diskutiert und gelangen dann in die Öffentlichkeit. Es ist wirklich ärgerlich, wenn jedes Mal, wenn ein Dokument für eine breitere Diskussion geöffnet wird, alle alten Links dazu kaputtgehen! Jetzt wechseln wir zu einem einfachen Datumsformat.
• Dateierweiterung. Ein sehr verbreitetes Phänomen. „cgi“, sogar „.html“ werden sich in Zukunft ändern. Möglicherweise werden Sie in 20 Jahren kein HTML mehr für diese Seite verwenden, aber die heutigen Links müssen trotzdem funktionieren. Die kanonischen Links auf der W3C-Website verwenden keine Erweiterung (wie das gemacht wird).
• Programmiermechanismen. Suchen Sie in der URI nach „cgi“, „exec“ und anderen Begriffen, die schreien „schau, welche Software wir verwenden“. Will jemand sein ganzes Leben den Perl CGI-Skripten widmen? Nein? Dann entfernen Sie die Erweiterung .pl. Lesen Sie das Serverhandbuch, wie das geht.
• Laufwerksname. Ach komm! Aber ich habe so etwas schon gesehen.

Also das beste Beispiel von unserer Website ist einfach

http://www.w3.org/1998/12/01/chairs

… ein Bericht über das Protokoll des Sitzens der W3C-Vorsitzenden.

Themen und Klassifikation nach Themen

Ich werde ausführlicher über diese Gefahr sprechen, da es eine der schwierigsten Dinge ist, zu vermeiden. In der Regel gelangen Themen in die URI, wenn Sie Ihre Dokumente nach der durchgeführten Arbeit klassifizieren. Aber diese Aufschlüsselung wird sich im Laufe der Zeit ändern. Die Bezeichnungen der Bereiche werden sich ändern. Im W3C wollten wir MarkUP in Markup und dann in HTML ändern, um den tatsächlichen Inhalt des Abschnitts widerzuspiegeln. Außerdem gibt es hier oft einen flachen Namensraum. Nach 100 Jahren werden Sie mit Sicherheit nichts davon wiederverwenden wollen? In unserem kurzen Leben wollten wir bereits Begriffe wie „Geschichte“ und „Stylesheets“ wiederverwendet sehen.

Es ist eine verlockende Art, eine Website zu organisieren — und tatsächlich eine sehr verlockende Art, alles zu organisieren, einschließlich des gesamten Webs. Es ist eine ausgezeichnete mittelfristige Lösung, hat aber ernsthafte Nachteile auf lange Sicht.

Teilweise liegen die Gründe in der Philosophie des Bedeutungsinhalts. Jeder Begriff in der Sprache ist ein potenzielles Clusterobjekt, und jeder Mensch kann eine unterschiedliche Vorstellung davon haben, was er bedeutet. Da die Beziehungen zwischen den Subjekten eher einem Netz als einem Baum ähneln, können selbst diejenigen, die sich mit dem Netzwerk einig sind, eine andere Baumdarstellung wählen. Das sind meine (häufig wiederholten) allgemeinen Anmerkungen zu den Gefahren hierarchischer Klassifikation als allgemeine Lösung.

Tatsächlich binden Sie sich, wenn Sie einen Themenbegriff in der URI verwenden, an eine bestimmte Klassifikation. Möglicherweise bevorzugen Sie in Zukunft eine andere Option. Dann wird die URI anfällig für Verstöße.

Der Grund, warum ein Themenbereich als Teil der URI verwendet wird, liegt darin, dass die Verantwortung für die Unterbereiche des URI-Raums normalerweise delegiert wird, und daher benötigen Sie den Namen der organisatorischen Einheit — einer Abteilung, Gruppe oder etwas anderem, das für diesen Unterraum verantwortlich ist. Dies bindet die URI an die organisatorische Struktur. Normalerweise ist dies nur sicher, wenn weiter (links) die URI durch ein Datum geschützt ist: 1998/pics könnte für Ihren Server „das, was wir 1998 unter pics verstanden haben“, statt „das, was wir 1998 mit dem gemacht haben, was wir jetzt pics nennen“, bedeuten.

Vergessen Sie nicht den Domainnamen

Denken Sie daran, dass dies nicht nur den Pfad in der URI betrifft, sondern auch den Servernamen. Wenn Sie separate Server für verschiedene Dinge haben, sollten Sie sich bewusst sein, dass diese Trennung nicht mehr geändert werden kann, ohne viele, viele Links zu zerstören. Einige klassische Fehler wie „sehen Sie, welche Software wir heute verwenden“ – Domainnamen wie "cgi.pathfinder.com", "secure", "lists.w3.org". Diese wurden erstellt, um die Serveradministration zu erleichtern. Egal, ob die Domain eine Abteilung in Ihrem Unternehmen, den Dokumentstatus, Zugriffsebenen oder Sicherheitsstufen repräsentiert, seien Sie sehr, sehr vorsichtig, bevor Sie mehr als einen Domainnamen für verschiedene Dokumenttypen verwenden. Denken Sie daran, dass Sie viele Webserver innerhalb eines sichtbaren Webservers verstecken können, indem Sie Umleitungen und Proxys verwenden.

Ja, und denken Sie auch über Ihren Domainnamen nach. Sie möchten nicht, dass Sie als seife.com bezeichnet werden, nachdem Sie Ihre Produktlinie geändert haben und mit der Seifenproduktion aufhören (Entschuldigung an denjenigen, der derzeit soap.com besitzt).

Fazit

Die Beibehaltung der URIs über 2, 20, 200 oder sogar 2000 Jahre ist offensichtlich nicht so einfach, wie es scheint. Dennoch treffen Webmaster im gesamten Internet Entscheidungen, die es ihnen in Zukunft wirklich erschweren. Oft geschieht dies, weil sie Werkzeuge verwenden, deren Aufgabe es ist, die beste Website nur im Moment darzustellen – und niemand hat bedacht, was mit den Links passiert, wenn sich alles ändert. Der Punkt hier ist jedoch, dass sich vieles, sehr vieles ändern kann, und Ihre URIs gleich bleiben müssen. Dies ist nur möglich, wenn Sie darüber nachdenken, wie Sie sie erstellen.

Siehe auch:

• Jakob Nielsen's Ausführungen zum selben Thema

Ergänzungen

Wie man Dateierweiterungen entfernt…

…aus URIs im aktuellen Webserver basierend auf Dateien?

Wenn Sie beispielsweise Apache verwenden, können Sie es so konfigurieren, dass es den Inhalt abstimmt. Behalten Sie die Dateierweiterung (z. B. .png) in der Datei (z. B. mydog.png), aber man kann auch ohne sie auf Webressourcen verlinken. Dann überprüft Apache das Verzeichnis auf das Vorhandensein aller Dateien mit diesem Namen und jeder Erweiterung und kann das beste aus einer Auswahl wählen (zum Beispiel GIF und PNG). Es ist nicht nötig, verschiedene Dateitypen in verschiedene Verzeichnisse zu legen; tatsächlich wird die Inhaltsverhandlung nicht funktionieren, wenn Sie das tun.

• Konfigurieren Sie Ihren Server für die Inhaltsverhandlung
• Verlinken Sie immer auf URIs ohne Erweiterung

Links mit Erweiterungen funktionieren zwar weiterhin, erlauben es Ihrem Server jedoch nicht, das beste derzeit verfügbare und zukünftige Format auszuwählen.

(Tatsächlich, meinHund, mydog.png und mydog.gif — gültige Webressourcen, meinHund — dies ist eine Ressource mit universellem Inhaltstyp, und mydog.png und mydog.gif — Ressourcen eines bestimmten Inhaltstypens).

Natürlich, wenn Sie Ihren eigenen Webserver schreiben, wäre es nicht schlecht, eine Datenbank zu verwenden, um dauerhafte Identifikatoren mit ihrer aktuellen Form zu verknüpfen, obwohl Sie vor unbegrenztem Wachstum der Datenbank aufpassen sollten.

Schandtafel — Geschichte 1: Channel 7

Im Jahr 1999 habe ich die Schließungen von Schulen aufgrund von Schnee auf der Seite verfolgt http://www.whdh.com/stormforce/closings.shtml. Mann kann nicht warten, bis die Informationen am unteren Bildschirmrand erscheinen! Ich habe einen Link von meiner Homepage gesetzt. Der erste große Schneesturm des Jahres 2000 kommt, und ich überprüfe die Seite. Dort steht:

— Stand.
Aktuell ist nichts geschlossen. Bitte kommen Sie bei Wetterwarnungen wieder.

Es kann nicht sein, ein ebenso starker Sturm. Lustig, dass das Datum fehlt. Aber wenn man zur Startseite der Website geht, gibt es eine große Schaltfläche „Geschlossene Schulen“, die zu einer Seite führt http://www.whdh.com/stormforce/ mit einer langen Liste geschlossener Schulen.

Vielleicht haben sie das System zur Beschaffung der Liste geändert — aber sie mussten die URI nicht ändern.

Schandtafel — Geschichte 2: Microsoft Netmeeting

Mit der wachsenden Abhängigkeit vom Internet kam die geniale Idee, Posts Links zur Website des Herstellers einzufügen. Dies wurde oft genutzt und stark missbraucht, aber — die URL darf nicht geändert werden. Neulich habe ich einen Link aus dem Client Microsoft Netmeeting 2/something im Menü Hilfe/Microsoft im Web/Kostenlose Sachen ausprobiert und erhielt einen Fehler 404 — Serverantwort nicht gefunden. Vielleicht wurde es bereits behoben…

©1998 Tim BL

Historische Anmerkung: Ende des 20. Jahrhunderts, als dies geschrieben wurde, war „cool“ ein Begriff der Zustimmung, besonders unter Jugendlichen, der auf Mode, Qualität oder Angemessenheit hinwies. In Eile wurde der URI-Pfad oft aus „Coolness“ ausgewählt, und nicht wegen Nützlichkeit oder Langlebigkeit. Diese Anmerkung ist ein Versuch, die Energie, die hinter der Suche nach Coolness steht, umzuleiten.

Quelle: habr.com