Jeder kennt das. Da hat man ein Lesezeichen zu einer Seite mit bestimmten Informationen seit ein paar Monaten gespeichert, möchte aus irgendeinem Grund wieder auf diese Seite und.. erhält einen 404, weil die Seite da nicht mehr auffindbar ist, da die Admins der Webseite beschlossen haben, die Pfade (URIs) zu ändern, neu zu strukturieren, zu verbessern, wie auch immer.
Ich habe auf jeden Fall heute ein tolles Dokument vom W3-Konsortium gefunden, welches die Überschrift “Cool URIs don’t change” trägt.
Hier mal die Dinge, die laut W3 nicht in eine URI hineingehören (fiktive Beispielpfade wie example/ sind kursiv und haben ein / am Ende..):
- Autor – Wenn das Dokument auf einmal nicht mehr von Peter sondern von Marie gewartet wird, wäre es extrem blöd, wenn sich der URI von http://example.com/peter/foo nach http://example.com/marie/foo ändern würde.
- Status – In der tat sind Pfade wie alt/ neu/ toll/ langweilig/ entwurf/ in jedem Fall irgendwann nicht mehr aktuell. Dokumente, die man anderen anbietet, in solchen Pfaden anzubieten, ist unschön. Noch dazu findet man die eigenen Dokumente ohne Suchfunktion nie wieder.
- Zugriff – Glaube persönlich nicht, dass das so häufig auftritt, aber der Vollständigkeit halber auch hier: Dokumente, die erst in kleinerem Kreis entwickelt werden, und dann langsam einem immer breiteren Publikum zugänglich gemacht werden, von einem Ordner in den nächsten verschieben, ist schlecht. draft/ für einen selbst ist vielleicht (solange man wirklich nur selbst Zugriff darauf hat) in Ordnung (siehe auch Status). Das Dokument von da aus aber nach reviewers/ zu verschieben, wo es nur ein paar Leute sehen können, dann später nach community/, wo es schon ein paar Leute bookmarken und am ende dann in den öffentlichen Bereich, ist unnötig.
- Dateinamenserweiterungen – Ich muss zugeben, selbst unter Linux machen die einen gewissen sinn. Doch nach außen hin sind sie unnötig. Niemand will wissen, ob das eine .html, .phtml, .as, .php[3-5]?, .cgi, .pl, .xhtml oder sonstwie Datei ist. Außerdem sind Erweiterungen bei URIs durchaus hinderlich. Nämlich dann, wenn die URI über Jahrzehnte hinweg gelten soll. Selbst .html und .xhtml werden irgendwann ausgestorben sein. Und dann? Dann soll das Dokument trotzdem noch unter der gleichen URI gefunden werden können. Im Dateisystem kann die hinter der URI verborgenen Datei natürlich eine Endung tragen. Apache (und ich denke so ziemlich jeder andere Webserver) machts möglich.
- Kennzeichen der Software – Hier gilt das gleiche wie bei den Erweiterungen. Ein Ordner namens cgi-bin/ interessiert den Leser 1. schlichtweg nicht, 2. kann es sein, dass in 3 Jahren das CGI- durch ein PHP-Script ersetzt wird. Wo es möglich ist, sollte man soetwas unterlassen.
Noch dazu ist in dem Artikel Subject aufgeführt, was ich ein wenig anders sehe. Der Autor dieses Empfehlungsdokuments hat dazu eine etwas längere Erklärung geschrieben:
Topics and Classification by subject
I’ll go into this danger in more detail as it is one of the more difficult things to avoid. Typically, topics end up in URIs when you classify your documents according to a breakdown of the work you are doing. That breakdown will change. Names for areas will change. At W3C we wanted to change “MarkUp” to “Markup” and then to “HTML” to reflect the actual content of the section. Also, beware that this is often a flat name space. In 100 years are you sure you won’t want to reuse anything? We wanted to reuse “History” and “Stylesheets” for example in our short life.
This is a tempting way of organizing a web site – and indeed a tempting way of organizing anything, including the whole web. It is a great medium term solution but has serious drawbacks in the long term
Part of the reasons for this lie in the philosophy of meaning. every term in the language it a potential clustering subject, and each person can have a different idea of what it means. Because the relationships between subjects are web-like rather than tree-like, even for people who agree on a web may pick a different tree representation. These are my (oft repeated) general comments on the dangers of hierarchical classification as a general solution.
Effectively, when you use a topic name in a URI you are binding yourself to some classification. You may in the future prefer a different one. Then, the URI will be liable to break.
Der Grund ist hier also, dass ein Titel, eine Überschrift oder eine Bezeichnung sich durchaus mit den Jahren ändern, oder man nach einiger Zeit vielleicht eine andere Bezeichnung vorzieht. Wie soll man eine Ressource (also ein Dokument) denn sonst Identifizieren (genau das macht einen URI ja aus), wenn nicht über die Bezeichnung?
Auf jeden Fall ist man auf der sicheren Seite, wenn man das Jahr oder das ganze Datum mit in den URI haut, denn so eine Bezeichnung wird sich selten innerhalb eines Tags in der Bedeutung ändern. (Genau das hab ich ja auch in meinen Perma-URLs im Blog: http://www.mitja-schmakeit.de/wordpress/jahr/monat/tag/bezeichnung/)
Falls hier also jemand in Zukunft ein Web-Projekt plant, denkt ruhig auch ein wenig an das Design der URIs der Seiten eures Projekts. Sofern ihr nicht auf Anfragen steht wie “Ich habe letztes Jahr diese Adresse bookmarked, wo finde ich die Seite jetzt?”. Wobei noch besser ist es, wenn man die Pfade gerade umgestellt hat, und Google noch auf die alten Verweist, was natürlich jedem Nutzer (und Google beim nächsten Besuch) einen hübschen 404 hinknallt. Wenn man schon die Pfade meint ändern zu müssen, dann doch bitte mit Weiterleitung. Und wenn ihrs ganz perfekt machen wollt, gebt bei Dokumenten, deren Leben vorüber ist, die also unter überhaupt keiner Adresse mehr gefunden werden können, aber mal existiert haben, ein 410 – Gone zurück.