Der “Uniform Resource Locator” URL wurde 1994[2] von Tim Berners-Lee als Untermenge der “Uniform Resource Identificator” URI spezifiziert und hat sich in den darauffolgenden 16 Jahren als der tragende Standard neben HTML im WWW etabliert.
Bereits 1998 wurde Berners-Lee ein flammender Appell im W3C veröffentlicht, das Schema der URLs nicht zu missbrauchen und als langfristigen “Locator” zu designen und lesbar für Menschen zu gestalten.
Gute Beispiele im seinen Sinn sind (“coole URLS”):
- http://www.w3.org/standards/xml/core#summary
- http://www.mediawiki.org/wiki/Manual:Short_URL
- http://www.enterprise2punkt0.at/2010/02/category-label-tag-keyword-die-bunte-neue-welt.html
- http://community.jboss.org/thread/145917
Sollte es einmal nicht möglich, dass sich die URL nicht mit der Zeit ändert, wird üblicherweise eine “permanente URL” angeboten:
http://community.jboss.org/wiki/JBossPortletBridge entspricht http://community.jboss.org/docs/DOC-10721
Schlechte Beispiele sind:
- ein Blogbeitrag auf Liveray – http://www.liferay.com/c/blogs/find_entry?redirect=%2Fcommunity%2Fblogs&noSuchEntryRedirect=http%3A%2F%2Fwww.liferay.com%2Fcommunity%2Fblogs%3Fp_p_id%3D115%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_pos%3D1%26p_p_col_count%3D2%26_115_struts_action%3D%252Fblogs_aggregator%252Fview_entry%26_115_entryId%3D4622100&entryId=4622100
- Aufruf eines Portlets im JBoss Portal – http://intranet-portal.sozvers.at/portal/auth/portal/svportal/WebekuPage/WebekuWindow?actionMethod=views%2Fkto_liste.xhtml%3AbuchungsgegenstaendeAction.setInitialized%28false%29&cid=146&action=1&org.jboss.portletbridge.NAMESPACE=jbpns_2fsvportal_2fWebekuPage_2fWebekuWindowsnpbj&org.jboss.portletbridge.VIEWID=%2Fviews%2Fbgs_liste.xhtml
Ein Grund warum die letzten Beispiele als schlecht bewertet werden liegt sicherlich auf der Hand: sie sind unnötig lang und nicht lesbar. Es ist nicht klar, ob die verlinkte Resource eine HTML Seite, ein Bild, einen REST Aufruf oder eine Suchmaske darstellt.
Die Konsequenzen darüber hinaus sind weniger offensichtlich. In vielen dieser Fälle (z.B. der JBoss Portal Link) verlieren die URLs ihre Bedeutung wenn die Benutzersession beendet wird und führen danach immer zu den selben “default” Inhalten, z.B. Einstiegsseite des Portlets. Damit können schlechte URLs nicht im Browser als Bookmarks gespeichert oder per Email verschickt werden oder nicht von anderen Applikationen aufgerufen werden um z.B. Kontaktdaten abzufragen.
Der Java Portal Meanstream hat diesen Punkt komplett veschlafen. Nicht zufälliger Weise sind die schlechten URL Beispielen von Portalseiten entnommen, die nach JSR 168 entwickelt wurden. Die Potaltechnologie weicht hier grundlegend vom ursprünglichem Konzept der URL ab. Leider ist dort keine Besserung in Sicht, was einige wenige Portalhersteller mit Workarounds zu beseitigen versuchen.
Hiermit zu meinem persönlichen flammenden Appell: URLs auch innerhalb des Unternehmens als “coole URLs” zu designen.
@Klaus-M. Schremser (Gentics): wie habt ihr das bei eurem Produkt gelöst?
Beispiele mit coolen/uncoolen Links sind erbeten.
Sorry, aber die Umsetzung von URLs ist nicht Teil des JSR168 oder JSR286. Die Umsetzung der URL-Funktionalität ist Teil der Vendor-Implementierung.
Es gibt durchaus Implementierungen, die eine Konfiguration oder Umsetzung von lesbaren “permanent” URLs zulassen. Es ist aber doch so, dass der render-state mit in der URL kodiert werden muss, sobald der Benutzer etwas daran ändert um genau den Fall abzudecken, dass der Link eben nicht die Bedeutung verliert, wenn er verschickt wird. – Hier widersprechen sich die zwei in Ihrem Posting erwähnten Requirements etwas, nicht?
Ich kann nicht nachvollziehen, wieso der Java Portal Mainstream hier etwas verschlafen haben sollte.
Hallo Micha, hallo Gerhard,
ich bin auch der Meinung, dass diese Vorgabe in der Spezifikation stehen sollte und ein Muss ist, sonst passiert es teilweise nicht. Bei Gentics Portal.Node (Java Portal) hatten wir es zuerst auch nicht (weil ja nicht Teil der Spezifikation) und das war ein großer Fehler – haben wir jetzt korrigiert – es gibt das Feature Beautiful URLs
.
Aber ich denke wir reden hier über Techniker vs. Anwender Sicht und da ist es wie bei Windows und Google
– wer hat da Recht? 
Ich sage natürlich die Anwender haben Recht und für die muss es passen, weil die müssen schlussendlich damit arbeiten – aber das ist IMHO.
mfg kms
@Klaus: Bzgl dem Inhalt des JSR168 oder JSR286 muss ich dir widersprechen. Die Java Portlet API spezifiziert die Schnittstelle zwischen dem Hersteller der diesen JSR implementiert und den Applikationsentwicklern.
Die Endanwender sind davon nicht betroffen, nachdem sie keine Applikationen entwickeln. Das Benutzerinterface, und dazu gehören auch die URIs, welches die Applikationsentwickler oder die Hersteller für den Endanwender vorsehen ist nicht im Scope dieser Schnittstelle. – Abgesehen von notwendigen Applikationsschnittstellen für die Entwickler, wie encodeURL().
Ich sehe hier keinen Widerspruch ob es um Techniker oder Anwender geht. Unser Produkt muss für die Kunden das richtige sein und hier sehe ich sowohl die Entwickler, Systemadministratoren, als auch Anwender und Fachbereiche.
Offene Standards zu unterstützen ist eine der Grundanforderungen unserer Kunden, aber kein Wettbewerbsvorteil. Ein offener Standard ist aber sicher nicht der richtige Ort um Herstellern spezifische Produktfeatures vorzuschreiben.
Wie ein Portal funktioniert, wie die Pageverwaltung aussieht, und wie diese inkl. Berechtigungssystem auf die URIs umgelegt wird, ist implementationsspezifisch und ich kann daran nichts negatives finden. – Hätte der Standard diese URIs vorgeschrieben wäre eure Umsetzung der “beautiful URLs”, wie ihr sie nennt, wohl gar nicht standardkonform umsetzbar gewesen.