Stand: 2012-05-08

Perfekte URIs

Was macht gute URIs aus und wie gestaltet man sie?

Inhalt

Anforderungen an URIs

Dauerhaft sollen URIs sein, damit bestehende Verweise nicht irgendwann ins Leere führen und wertlos werden.

Kurz sollen URIs sein, weil die Gefahr zerstörerischer Umbrüche in E-Mails geringer ist und sie leichter mündlich übermittelt oder aus einem Druckerzeugnis abgeschrieben werden können. Im Idealfall kann man sie sich sogar merken wie bei http://example.com/jobs. Lange URIs werden dagegen regelmäßig mit Hilfe von Diensten wie TinyURL.com verkürzt und so nicht nur das eigentliche Ziel verschleiert, sondern das Schicksal einer URI auch noch an einen Dienst geknüpft, der jederzeit eingestellt werden kann!

Suchmaschinenfreundlich sollen URIs sein, damit angebotene Inhalte und Dienste möglichst gut gefunden werden.

Beschreibend sollen URIs sein, damit potenzielle Besucher eine Vorstellung bekommen, wohin sie führen. Ein Link wie http://de.wikipedia.org/wiki/Eiffelturm sagt mehr als http://de.wikipedia.org/wiki/87629. Mehrere Wörter werden am besten durch Bindestriche getrennt, weil sie besser erkennbar und leichter einzugeben sind als Unterstriche und den Lesefluss weniger stören als zum Beispiel das +-Zeichen. Stichwörter in URIs sind außerdem bei der automatischen Vervollständigung im Browser nützlich, falls der Nutzer den URI bereits aufgerufen hatte.

Einfach einzugeben sollen URIs sein, um sie leicht aus gedruckten Medien übertragen zu können. Großbuchstaben und Zeichen, die maskiert werden müssen (Umlaute, Sonderzeichen), sollten möglichst nicht in URIs vorkommen.

Was gehört nicht in URIs?

Die wichtigste Regel zur Erzeugung dauerhafter URIs ist, alles wegzulassen, was sich ändern könnte. Dazu zählt insbesondere:

Hinweise auf die eingesetzte Technologie wie .php oder .jsp haben nichts in URLs zu suchen, weil sich die serverseitigen Technologien mit großer Wahrscheinlichkeit ändern werden und weil sie außerdem für den Besucher völlig unwichtig sind. Besonders schlecht sind URIs, die Implementierungsdetails wie wicket:interface=:0:form:tabbedPanel:tabs-container:tabs:0:link::ILinkListener:: enthalten. Diese URIs sind voll von Dingen, die sich ändern werden.

Dateiendungen wie .html, die den Inhaltstyp angeben, sind vermutlich relativ dauerhaft, aber auch HTML und andere Dateiformate werden wahrscheinlich irgendwann abgelöst, weshalb sie möglichst nicht im URI vorkommen sollten. Andererseits will der Nutzer manchmal ein Dokument in einem ganz bestimmten Dateiformat herunterladen und kann das am einfachsten mit einer bestimmten Dateiendung tun. Die Standardrepräsentation einer Ressource (meistens HTML) sollte jedoch ohne Endung angegeben werden.

Verzeichnisebenen spiegeln immer eine ganz bestimmte Sicht auf Ressourcen wieder, die aber fast nie für alle Zeit passt. Selbst vermeintlich für die Ewigkeit bestehende Strukturen wie http://example.com/deutschland/brandendurg/potsdam können sich ändern; wenn Berlin und Brandenburg eines Tages doch verschmelzen sollten, heißt das entstehende Bundesland vielleicht nicht Brandenburg. Eine der wenigen beständigen hierarchischen Gliederungen ist das Erscheinungsdatum eines Artikels (http://example.com/2012/05/06/ein-artikel), denn er kann ja kein zweites Erscheinungsdatum bekommen. Am besten haben URIs eine möglichst flache Struktur, wie es zum Beispiel bei der Wikipedia der Fall ist, wo alle Artikel auf einer Ebene liegen. Die Inhalte einer Website können auch ohne Verzeichnisebenen in den URIs gut geordnet werden.

Aktionen wie create oder update gehören grundsätzlich nicht in URIs, weil Ressourcen im Sinne von REST Substantive, also Dinge sind. Welche Operation auf einer Ressource ausgeführt werden soll, wird stattdessen mit einem HTTP-Verb wie GET oder PUT angegeben.

Sitzungsschlüssel ändern sich naturgemäß ständig und sollten deshalb nie in URIs vorkommen. Sie bergen auch ein Sicherheitsrisiko, weil beim Öffnen von Links zu externen Websites per HTTP-Referer oder durch bewusstes Weitergeben von URIs der Sitzungsschlüssel in falsche Hände geraten kann. Es gibt zwar mehr oder weniger gute Umgehungslösungen für diese Probleme, aber noch besser ist es, sie ganz zu vermeiden und Cookies oder HTTP-Authentifizierung zu nutzen.

Suchmaschinenoptimierung

Aus rein technischer Sicht sind URIs wie http://example.com/articles/34562 mit künstlichen Schlüsseln (hier 34562) am besten. Sie enthalten nichts, was sich irgendwann ändern müsste. Noch dazu sind diese Links kurz und lassen sich gut weitergeben. Aber Links dieser Art sind für Suchmaschinen nicht optimal. Ob Suchmaschinen bei der Sortierung der Ergebnisse wirklich Schlüsselwörter in URIs berücksichtigen, ist umstritten, aber die Mehrheit der Suchmaschinenoptimierer scheint davon auszugehen. In jedem Fall dürften Schlüsselwörter im URI für die Position in den Ergebnissen nicht schädlich sein, so lange es nicht übermäßig viele sind oder sie nicht zum Inhalt passen, was nach Spam riechen würde. Wenig aussagekräftige Füllwörter wie "bei", "mit" und ähnliche sollten vermieden werden, denn sie machen URIs unnötig lang und verschlechtern das Signal/Rausch-Verhältnis.

Der entscheidende Vorteil von Stichwörtern in URIs ist, dass Nutzer von Suchmaschinen stolze 25 % der Zeit die URIs betrachten, wenn sie die Suchergebnisse erfassen! Wenn sich die gesuchten Wörter im URI wiederholen, ist das für den Benutzer ein wichtiger Hinweis, dass ein Link zum gewünschten Ziel führen könnte. Suchergebnisse

Bei sprechenden URIs ist allerdings die Gefahr recht groß, dass sie sich ändern, weil sich zum Beispiel der Titel einer Seite ändert. Ein verbreiteter Kompromiss zwischen dauerhaften und lesbaren URIs ist die Kombination eines künstlichen Schlüssels mit angehängten Stichwörtern: http://stackoverflow.com/questions/739654/understanding-python-decorators. Den Teil nach dem letzten Schrägstrich kann man beliebig ändern oder ganz weglassen und kommt trotzdem zum Ziel, weil lediglich die enthaltene Nummer entscheidend ist. Bestehende Verweise zerbrechen also nicht, wenn der Autor den Titel ändert; lediglich der im URI wiederholte Titel passt nicht mehr ganz. Dieses Verfahren bietet sich an, wenn ein System viele URIs umfassen wird und es zu aufwändig wäre, für jede Ressource bewusst einen URI zu wählen.

Mehrere URIs zu einer Ressource sollten vermieden werden, weil Suchmaschinen das als Spamming-Versuch negativ auslegen könnten. Trotzdem können verschiedene URIs zu demselben Inhalt sinnvoll sein, wenn es zum Beispiel einen URI zur jeweils aktuellen Version von etwas geben soll und alle Versionen dauerhaft erreichbar sein sollen: http://example.com/releases/current würde für eine bestimmte Zeit zu demselben Inhalt führen wie http://example.com/releases/2.10.3, aber der erste URI bezeichnet die Ressource "aktuelle Version" und der zweite "Version 2.10.3". Google empfiehlt in diesem Fall, sich für einen URI zu entscheiden und die anderen mit dem passenden HTTP-Status umzuleiten. In meinem Beispiel wäre es eine vorübergehende Umleitung mit dem HTTP-Status 303 oder 307; bei einer dauerhaften Umleitung wäre der Status 301 korrekt.

Sonstiges

Wenn sich ein URI doch ändert, sollte es eine Weiterleitung mit dem HTTP-Status 301 zum neuen Ziel geben - und zwar solange, wie es die Ressource gibt.

Es gibt Entwickler, die der Überzeugung sind, dass Datenbank-IDs nicht in URIs gehören würden, weil es sich dabei um "Implementierungsdetails" handeln würde. Ich halte dieses Argument für unsinnig, denn wozu sollte man neben der Spalte mit dem Primärschlüssel eine Spalte mit einem weiteren künstlichen Schlüssel anlegen? Sollte eines Tages eine völlig andere Speichertechnologie, die keine Primärschlüssel benötigt, eingesetzt werden, können die bestehenden Primärschlüssel immer noch in "Web-IDs" umgewidmet werden.

Zusammenfassung

Ein guter URL ändert sich nie, ist kurz und enthält nach Möglichkeit relevante Stichwörter. Ein guter Kompromiss aus Lesbarkeit und Beständigkeit ist die Verwendung von künstlichen Schüsseln mit angehängten Stichwörtern. Im Zweifelsfall ist man mit kurzen URIs, die im Wesentlichen aus einem technischen Schlüssel bestehen, auf der sicheren Seite.

Weitere Information