In den letzten Jahren habe ich mich für Usability und Webdesign interessiert. Einer der Bereiche, der beim Design einer Website oft übersehen wird, ist das Design derURIs auf dieser Website. ModerneCMSSysteme ermöglichen unterschiedliche Grade der URI-Anpassung, aber die Standardeinstellungen sind oft nicht so benutzerfreundlich, wie sie sein könnten, und URIs werden oft zuletzt im Designprozess platziert.
Saubere URIs sind ein Bestandteil einer sauberen Website, und zwar ein wichtiger. Der Großteil des Endnutzerzugangs zum Internet beinhaltet eine URI, und ob der Benutzer die URI tatsächlich eingibt oder nicht, arbeitet er dennoch mit einer.
Zuerst möchte ich über die Leitprinzipien des URI-Designs sprechen, dann über die praktische Umsetzung dieser Prinzipien.
Hinweis: Ursprünglich habe ich diesen Artikelentwurf mit dem Begriff „URL“ verfasst, aber da „URL“ größtenteils durch „URI“ ersetzt wurde, habe ich ihn aktualisiert, um den Begriff URI zu verwenden. Weitere Informationen vom W3C.
Prinzipien
Werfen wir zunächst einen Blick auf einige der allgemeinen Prinzipien des URI-Designs.
Eine URI muss ein Objekt eindeutig und dauerhaft repräsentieren
Eine der grundlegendsten Philosophien hinter einer URI ist, dass sie ein Datenobjekt im Internet repräsentiert. Die URI muss eindeutig sein, so dass sie eine Eins-zu-eins-Entsprechung ist – eine URI pro Datenobjekt.
Obwohl dies immer das Ziel ist, gibt es Zeiten, in denen es sehr schwierig oder unmöglich ist, dies zu erreichen. Kanonische URL-Tags wurden erfunden, um die Menge an doppeltem Inhalt, die von einer Suchmaschine gesehen wird, zu reduzieren. Obwohl sie keine endgültige Lösung sind, werden kanonische URLs dringend empfohlen, da große Suchmaschinen wie Google ihnen jetzt Aufmerksamkeit schenken. Weitere Informationen zu kanonischen URLs finden Sie in diesem Artikel von SEOmoz.
URIs sollten auch dauerhaft sein (d.h. die URI einmal wählen und dabei bleiben). Dies spricht für ein gutes URI-Design vor dem Start einer Website, wobei die URIs sorgfältig geplant werden. Es wird eine Zeit kommen, in der Sie Verbesserungen an Ihren Entscheidungen vornehmen oder die URI-Struktur anderweitig ändern müssen. Wenn dies notwendig wird, stellen Sie sicher, dass Sie auf Ihrem Server HTTP 301 Moved Permanently-Weiterleitungen einrichten. Dies teilt Browsern und Suchmaschinen den neuen Speicherort des Inhalts mit und bewahrt auch jeglichen PageRank, den die alte URI angesammelt hat.
So benutzerfreundlich wie möglich sein
Dies ist der fundamentalste treibende Faktor hinter dem URI-Design (oder sollte es sein). URIs sollten mit dem Endbenutzer im Hinterkopf entworfen werden. Suchmaschinenoptimierung (SEO) und einfache Entwicklung sollten an zweiter Stelle stehen.
Eine Möglichkeit, eine URI benutzerfreundlich zu halten, besteht darin, sie kurz und prägnant zu halten. Das bedeutet, so wenig Zeichen wie möglich zu verwenden, während die Benutzerfreundlichkeit erhalten bleibt. Also ist /about besser als /about-acme-corp-page. Während man danach strebt, so kurz wie möglich zu sein, sollte man diese Benutzerfreundlichkeit nicht opfern, indem man URIs wie /13d2 verwendet, da dies für die Endbenutzer keine Bedeutung hat.
Umgekehrt wird die Verwendung eines Kurzlinks beim Teilen einer URI empfohlen. Dies ist großartig zum Twittern von Links auf Twitter oder zum Teilen auf sozialen Websites wie Facebook oder Google Buzz. Es ist großartig, wenn Sie Ihren eigenen URI-Shortener aus SEO-Gründen kontrollieren können, obwohl eine Website wie Bit.ly auch gut ist. Ich persönlich verwende PrettyLink Pro (ein WordPress-Plugin), um meine kurzen URIs zu erstellen. Eine Alternative ist das Short URL-Plugin.
WordPress bietet eine Schaltfläche an, um einen Kurzlink zu einem Beitrag zu erhalten, basierend auf dem WordPress-eigenen Format /?p=XXX, das wahrscheinlich kürzer ist als Ihre gewählte Permalink-Struktur. Der Vorteil ist, dass dies funktioniert, solange Ihre Website existiert. Der Nachteil ist, dass die Kürze des Links von der Länge Ihres Domainnamens abhängt.
Die URI sollte sich nicht auf Informationen verlassen, die für den Inhalt oder den Benutzer unwichtig sind. Ein häufiges Beispiel hierfür ist die Verwendung der Datenbank-ID als URI, wie in /products/23. Der Endbenutzer interessiert sich nicht dafür, dass das Produkt die Datenbank-Datensatznummer 23 ist, daher ist eine URI wie /products/kugelschreiber viel besser. Es kann verlockend sein, auf eine so schlechte URI-Struktur zurückzugreifen, da es auf dem Backend oft einfacher ist, die Datenbank mit einer ID abzufragen, anstatt eine Suche nach einem Alias durchführen zu müssen, um das Objekt zu finden.
Ein guter Test, um festzustellen, ob eine URI benutzerfreundlich ist, ist der "sprechfreundliche" Test. Man sollte eine URI in einem Gespräch mit einem Freund erwähnen können, und sie sollte Sinn ergeben. Zum Beispiel
Meine Biografie ist auf domain Punkt com Schrägstrich jim
anstelle von
Meine Biografie ist auf domain Punkt com Schrägstrich Seite Schrägstrich g g 2 3
Konsistenz
URIs auf einer Website müssen im Format konsistent sein. Sobald Sie Ihre URI-Struktur gewählt haben, bleiben Sie konsistent und folgen Sie ihr! Eine gute URI-Struktur für einen Teil der Website bedeutet, dass Sie insgesamt immer noch eine schlechte Struktur haben. Damit ein Benutzer darauf vertrauen kann, dass URIs auf einer Website auf eine bestimmte Weise funktionieren, muss das Format konsistent sein. Wenn Sie die Struktur wechseln müssen (vielleicht aktualisieren Sie eine schlecht gestaltete Website), verwenden Sie 301-Weiterleitungen, wie zuvor erwähnt.
"Hackbare" URIs
Im Zusammenhang mit der Konsistenz sollten URIs so strukturiert sein, dass sie verständlich „hackbar“ oder veränderbar sind. Wenn zum Beispiel /events/2010/01 einen monatlichen Kalender mit Ereignissen vom Januar 2010 anzeigt, dann sollte
- /events/2009/01 einen Veranstaltungskalender für Januar 2009 anzeigen
- /events/2010 sollte Veranstaltungen für das gesamte Jahr 2010 anzeigen
- /events/2010/01/21 sollte die Ereignisse vom 21. Januar 2010 anzeigen
Schlüsselwörter
Die URI sollte aus Schlüsselwörtern bestehen, die für den Inhalt der Seite wichtig sind. Wenn die URI also für einen Blog-Beitrag mit einem langen Titel ist, sollten nur die Wörter, die für den Inhalt der Seite wichtig sind, in der URI enthalten sein. Wenn der Blog-Beitrag beispielsweise „Meine Reise zu Best Buy für Speicherkarten“ lautet, könnte die URI /posts/2010/07/02/reise-best-buy-speicherkarten oder etwas Ähnliches sein.
Als Nebeneffekt verbessert die Verwendung wichtiger Schlüsselwörter in der URI die SEO. Meine persönliche SEO-Philosophie ist, dass man, anstatt für Suchmaschinen zu optimieren, für gute Inhalte optimieren sollte. Suchmaschinen haben es sich zum Ziel gesetzt, die besten Inhalte im Web zu finden, daher wird meiner Meinung nach alles getan, um eine benutzerfreundliche Website mit großartigen Inhalten und Möglichkeiten für weitere Informationen (Links) zu schaffen, die besten langfristigen Ergebnisse für die Sichtbarkeit in Suchmaschinen erzielen.
Technische Details
Wir haben einige der Leitprinzipien des URI-Designs behandelt. Nun wollen wir uns einige technische Umsetzungen dieser Richtlinien ansehen.
Keine Anzeichen der zugrunde liegenden Technologie
Die URI sollte keine .html, .htm, .aspx (ein großes Ärgernis) oder etwas anderes angehängt haben, das nur dazu dient, die zugrunde liegende Technologie anzuzeigen. Kein Endbenutzer interessiert sich dafür, ob Ihre Website in ASP.NET (.aspx), ColdFusion (.cfm) geschrieben wurde oder Server Side Includes (.shtml) verwendet – oder zumindest die meisten Endbenutzer nicht. Die zusätzlichen Informationen sind nur zusätzliche Eingabe und zusätzlicher Raum für Fehler und Frustration.
Die einzige Ausnahme von dieser Regel ist das Anhängen eines Postfix wie .atom, .rss oder .json an eine URI, um anzufordern, dass das bestimmte Format zurückgegeben wird. Alternativ könnte das Format mit dem Accept HTTP-Header angefordert werden.
Kein WWW
Das www. sollte aus der Website-URI entfernt werden, da es unnötiges Tippen ist und gegen die Regeln verstößt, so benutzerfreundlich wie möglich zu sein und keine unnötigen Informationen in die URI aufzunehmen.
Viele Benutzer geben jedoch immer noch das www.-Präfix ein, daher sollte www.domain.com per 301-Weiterleitung auf domain.com umleiten. Das Gleiche gilt für die 301-Weiterleitung von www.subdomain.domain.com auf subdomain.domain.com.
Format
URIs sollten im Format
domain.com/[Schlüsselinformationen]/[Name]/?[Modifikatoren]
Schlüsselinformationen sind Informationen, die nicht der Objektidentifikator (wie der Beitragstitel) sind, aber dennoch entscheidend für den Zugriff auf das Objekt. Dies kann beinhalten:
- die Art der Sache (d.h. Beiträge)
- die übergeordnete Kategorie (d.h. Technologie)
- wichtige Datenmember (d.h. das Veröffentlichungsdatum)
Modifikatoren ändern die Ansicht, nicht das dargestellte Datenmodell, und sind daher Teil des Abfrage-Strings und nicht der URI selbst.
Die Menge an „Schlüsselinformationen“ sollte auf ein Minimum beschränkt werden, da URIs nicht übermäßig verschachtelt sein sollten. Jeder im Abschnitt der Schlüsselinformationen platzierte Punkt muss wirklich entscheidend für die Adressierung der Seite sein.
Am Ende sollte die URI eine absteigende Hierarchie darstellen. Zum Beispiel
- Domain
- Typ
- Kategorie
- Titel
Beispiel: http://domain.com/posts/servers/nginx-ubuntu-10.04. Bei Elementen mit Datumsangaben sollte das Format der absteigenden Hierarchie folgen
- Jahr
- Monat
- Tag
Beispiel: http://domain.com/news/tech/2007/11/05/google-announces-android.
Google News hat einige interessante Anforderungen für Webseiten, die in den Google News-Ergebnissen gelistet werden möchten – Google benötigt mindestens eine 3-stellige eindeutige Nummer. Da Google Zahlen ignoriert, die wie Jahreszahlen aussehen, wird eine 5- oder mehrstellige Zahl bevorzugt. Außerdem wird eine Google News-Sitemap empfohlen. Dies ist einer der Fälle, in denen Sie, wenn Sie unbedingt Google News ansprechen möchten, dieser minderwertigen URI-Struktur entsprechen müssen. Aber, wenn Sie müssen, stellen Sie sicher, dass Sie konsistent sind und dass sie immer noch hackbar ist (verwenden Sie zum Beispiel das Format yyyymmdd wie 20100701).
Alles Kleinbuchstaben
Alle Zeichen müssen klein geschrieben sein. Der Versuch, jemandem eine URI zu beschreiben, wenn Groß- und Kleinschreibung gemischt sind, ist nahezu unmöglich.
Wenn jemand die URI in gemischter Groß-/Kleinschreibung eingibt, sollte er per 301-Weiterleitung auf die kleingeschriebene Seite umgeleitet werden. Das klingt sehr schön, aber in der Praxis bin ich nicht genau sicher, ob das möglich ist... die Verwendung eines CMS, das alle Anfragen an eine einzige Datei umschreibt, wäre der einfachste Weg, dies zu erreichen, da das Skript die 301-Weiterleitung auf Kleinbuchstaben auslösen könnte, aber ich bin nicht sicher, ob es einen einfacheren Weg gibt (.htaccess-Regeln oder so).
Aktionen an die URI angehängt
Aktionen können an die URI angehängt werden, wie z.B. Anzeigen, Löschen, Bearbeiten usw. Nicht-destruktive Aktionen (die das Objekt nicht ändern) sollten mit einem HTTP GET angefordert werden, während destruktive Aktionen per POST an die URI gesendet werden sollten. Suchen Sie bei Google nach REST URI Design für weitere Informationen.
URI-Bezeichner sollten URI-freundlich gestaltet werden
Eine URI kann den Titel eines Beitrags enthalten, und dieser Titel kann Zeichen enthalten, die nicht URI-freundlich sind. Dieser Beitragstitel muss daher URI-freundlich gemacht werden. Zum Beispiel
- Alle Großbuchstaben werden in Kleinbuchstaben umgewandelt
- Zeichen wie é sollten in e umgewandelt werden (usw.)
- Leerzeichen sollten durch Bindestriche ersetzt werden
- Unbekannte Zeichen (!, @, #, $, %, ^, &, *, etc.) sollten durch einen Bindestrich ersetzt werden
- Doppelte Bindestriche (–) sollten durch einen einfachen Bindestrich ersetzt werden
- Wahrscheinlich vergesse ich noch weitere Regeln
Zeichen können URI-escaped werden (wie %20 für das Leerzeichen), aber dies ist aus vielen der oben genannten Gründe (zeigt Technologie, unnötiges Tippen usw.) im Allgemeinen eine schlechte Idee.
Lustige Idee
Verwenden Sie eine satzähnliche Struktur (Dank an Chris Shiflett)
chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done
Wenn Sie weitere URI-Richtlinien kennen, die ich vergessen habe, oder Kommentare zu denen haben, an die ich mich erinnert habe, würde ich sie gerne hören!
Danksagungen
Vielen Dank an die Forrst-Community, die die ersten (sehr) groben Entwürfe dieses Beitrags gesehen und viele aufschlussreiche Kommentare beigesteuert hat. Besonderer Dank geht an @chriscoyier, @caludio, @steerpike und @mattthehoople für die direkte Mitarbeit an der Richtlinienliste und an alle anderen Forrst-Kommentatoren für die hilfreiche Diskussion.
Vielen Dank an meinen Vater für das Korrekturlesen und die Überprüfung! Vielen Dank auch an Chris, der so freundlich war, anzubieten, dies auf CSS Tricks zu veröffentlichen!
"Keine Anzeichen der zugrunde liegenden Technologie"
Wie genau würden Sie das empfehlen?
Ich kenne eine Möglichkeit, dies zu tun, aber das scheint ein bisschen zu kompliziert zu sein…
Die Verwendung eines CMS sollte dieses Problem lösen… fast alle modernen CMS verwalten die sauberen URIs so, dass der .html (usw.) Teil verborgen bleibt.
Was .rss oder .atom betrifft, so können Sie dies in einem CMS mit benutzerdefinierten Aliasen einrichten (ich denke an Drupal), aber die einfachste Implementierung, die ich bisher gesehen habe, ist von Ruby on Rails.
Absolut. Rails macht das zum Kinderspiel :)
Stimmt, aber ich bin kein CMS-Mensch (noch nicht jedenfalls :P)
Die Frage ist also im Grunde: Wie würden Sie das machen, wenn Sie eine reine HTML-Site oder etwas ohne CMS schreiben würden?
Sie müssen mod_rewrite (auf Apache) verwenden, um die Endbenutzer-URL in die intern verwendete URL umzuschreiben.
Im Grunde legen Sie eine Reihe von Regeln in der .htaccess-Datei Ihrer Website fest (suchen Sie bei Google nach htaccess & mod_rewrite), die die harte Arbeit des Weiterleitens der Website dorthin erledigen, wo sie sein soll.
Das "Worst-Case-Szenario" hierfür wäre, die Standard-Seitenbehandlungsfunktion Ihres Webservers zu verwenden und Ihre Site in einer hierarchischen Verzeichnisstruktur zu organisieren. Im Grunde wird jeder Beitrag zu einer "index.html"-Datei im entsprechenden Unterverzeichnis.
Wenn Sie also example.com/news als URI haben, würden Sie einfach eine index.html-Datei in das Verzeichnis /news legen, und es "versteckt" die zugrunde liegende Technologie.
Das ist natürlich etwas umständlich, aber wenn Sie eine einfache Broschürenseite mit ein paar Seiten haben, könnte es akzeptabel sein.
@Speedgun
Alle hier vorgeschlagenen Lösungen würden funktionieren. Am einfachsten wäre jedoch die Verwendung der Apache-Direktive DirectoryIndex in Ihrer Serverkonfiguration oder .htaccess.
DirectoryIndex weist Apache im Grunde an: „Wenn keine Datei angegeben ist, verwende diese“. So würde ‚DirectoryIndex index.php‘ dazu führen, dass http://www.foo.com/bar tatsächlich auf http://www.foo.com/bar/index.php zugreift.
Natürlich funktionieren die anderen Lösungen besser für komplexere Dinge als ein paar Seiten, aber das sollte Ihnen bei einfacheren Websites den Einstieg erleichtern.
Verwenden Sie Apache MultiViews. Auf diese Weise sucht Apache beim "GET /some/path/file" nach "file.*" in "/some/path/" und sendet es mit dem richtigen Mime-Typ und auch der Sprache. Sehr schön.
Oder erstellen Sie eine "file.var", die definiert, was je nach Browseranfrage gesendet werden soll.
Viele Möglichkeiten.
Sie verwenden Apache Rewrite, nicht Multiviews oder seltsame Verzeichnisstrukturen. Der Kern ist, dass der Benutzer den Server nach einer URL fragt, und diese URL wird gemäß bestimmten Regeln umgeschrieben, und dann ist die umgeschriebene URL das, was der Server verwendet, um die Seite zurückzugeben.
Das einfachste Beispiel ist das Umschreiben von URLs, um am Ende ".html" hinzuzufügen. Der Benutzer fragt also nach /foo, und Sie schreiben das in /foo.html um, um die tatsächliche Datei zurückzugeben.
Wenn Sie Unterstriche in einer URL haben, sind diese für fast alle Benutzer schwer einzugeben. Wenn Sie also /was_sind_sie.html haben, geben Sie diesen Link nicht weiter, sondern verwenden Sie /was/sind/sie und schreiben Sie den Schrägstrich in einen Unterstrich um und fügen Sie ".html" hinzu, und die richtige Datei wird zurückgegeben.
Ich nehme einfach den Titel des Dokuments, schreibe ihn klein, ersetze Leerzeichen durch Schrägstriche, und das ist die URL. Der Artikel "Guidelines for URI Design" von CSS-Tricks wäre also
https://css-tricks.de/richtlinien/für/uri/design
Dann gibt es auf der gesamten Website keine Frage, wie der Link sein sollte. Man kann die URL für einen Artikel einfach aus seinem Namen ableiten. Das macht es ziemlich viel schwieriger, einen Link zu vermasseln.
Wenn sich der Titel ändert, lasse ich den Originaltitel bestehen, füge aber eine Weiterleitung zum neuen Artikel hinzu, so dass der alte Titel zu einem Synonym für den neuen Titel wird, anstatt eines 404-Fehlers.
Bezüglich Hamranhansenhansens Kommentar
Ich stimme nicht zu, dass das Ersetzen von Leerzeichen durch Schrägstriche die beste Lösung ist. Schrägstriche repräsentieren Verzeichnisse, und Verzeichnisse sind im Allgemeinen eine hierarchische Art, Informationen zu organisieren. Die Menschen verstehen diese Konvention und Maschinen verstehen sie sicherlich.
Das Beispiel „/guidelines/for/uri/design“ ist fast in Ordnung, besonders wenn die Website mehrere Artikel mit Titeln hat, die mit „guidelines“ beginnen, aber der Schrägstrich-Ansatz wird oft das Falsche über den Inhalt aussagen, auf den er verweist.
Denken Sie darüber nach – wenn ich eine URL sehe, die example.com/guidelines/for/uri/design enthält, werde ich denken, dass es wahrscheinlich weitere Artikel unter der Adresse example.com/guidelines/ gibt. Es kann jedoch sein, dass unter dieser Adresse nichts außer einem 404-Fehler zu finden ist.
Ich empfehle daher, Schrägstriche für tatsächliche hierarchische Verzeichnisse zu verwenden, die zur Organisation des Website-Inhalts beitragen, und Bindestriche „-“ zu verwenden, um die Leerzeichen in den Seitentiteln zu ersetzen – genau wie es die kanonische URI für diesen Artikel tut.
Nun, für eine statische Website würde ich wahrscheinlich .htaccess-Umschreibungsregeln (oder Nginx-Konfiguration, wenn Sie Apache nicht verwenden) verwenden, um die sauberen URIs zu erhalten. Ich gehe davon aus, dass es sich um eine relativ kleine Website handelt (da sie statisch ist), so dass Sie die .htaccess-Regeln jedes Mal aktualisieren könnten, wenn Sie eine Seite hinzufügen (offensichtlich ist das bei größeren Websites sehr unpraktisch).
Sie können mich gerne auf meiner Website kontaktieren, und ich helfe Ihnen gerne bei den Umschreibungsregeln.
Statisch oder dynamisch spielt keine Rolle. Beide verwenden URLs. Alles, was Sie mit Rewrite tun, ist, eine saubere URL in eine technische URL zu übersetzen. So können Sie /products/foo in /products.php?item=foo oder in /index.html?page=products&item=foo oder was auch immer Sie benötigen, umschreiben lassen.
Siehe auch
Cool! Danke für die Lösung!
Ja, danke :)
Vorsicht vor den "www"-Richtlinien oben. Wenn Sie eine große Website betreiben, denken Sie daran, dass Cookies, die von .domain.com gesendet werden, mit JEDER EINZELNEN HTTP-ANFRAGE gesendet werden. Wenn Sie eine große Anzahl von Subdomains haben, sollten Sie in Betracht ziehen, den gesamten Hauptverkehr AUF www umzuleiten, damit Sie z.B. Bilder von einer anderen Subdomain ohne den gesamten Cookie-Verkehr bereitstellen können.
Beachten Sie, was viele große Websites tun, wie Facebook.
Das ist wirklich interessant! Das Cookie-Problem hatte ich bisher nicht bedacht. Sie sagen also, dass ein Cookie, das von http://domain.com gesetzt wurde, an alle Anfragen unter http://*.domain.com gesendet wird? Ich bin definitiv kein Experte für Cookies!
Eine mögliche Umgehung wäre die Verwendung eines separaten Domainnamens für den statischen Inhalt oder vielleicht einfach die CDN-URI zu verwenden. Das ist jedoch nicht so sauber wie die Verwendung von static.domain.com. Aber kümmert sich der Endbenutzer um den statischen Domainnamen?
Dies mag einer jener Orte sein, an denen die Realität es unpraktisch macht, der optimistischen Richtlinie zu folgen. Obwohl es auf meinen Websites, bei dem Verkehrsaufkommen, das ich erhalte (im Grunde keines), wahrscheinlich kein Problem ist…
Ja, das stimmt. Aber mit so ziemlich allen Sprachen können Sie es spezifizieren. Zum Beispiel
setcookie("TestCookie", $value, time()+3600, "/scripts/", ".example.com");
Dieses Cookie ist also nur im Verzeichnis "/scripts" verfügbar, wird aber an alle Subdomains von example.com gesendet.
setcookie("TestCookie", $value, time()+3600, "/", "www.example.com");
Dieses wird nur mit allen Anfragen an http://www.example.com gesendet, muss aber natürlich von http://www.example.com gesetzt werden.
Die Verwendung von www bedeutet, dass, wenn Sie Ihre Bilder von media.example.com oder img.example.com bereitstellen, diese Anfragen keine Cookies übertragen. Sie haben Recht, dass die Verwendung von examplecdn.com denselben Zweck erfüllen würde, aber dann benötigen Sie mehrere Domains.
Ich würde den www.-Teil der URI auch nicht als „unnötige“ Information bezeichnen – es ist der Hostname des Webservers.
Das ist in verschiedenen Fällen ziemlich wichtig, einschließlich des oben genannten Cookie-Aspekts. Andere, die mir sofort einfallen, sind die Auswirkungen auf Edge Caching, Intranet-Sites, SSL-Verkehr (da http://www.domain.tld und domain.tld möglicherweise nicht auf dieselbe IP-Adresse auflösen) und so weiter.
Ein weiterer Nachteil des „www“-Vorschlags: Das Senden vieler 301-Weiterleitungen zur Änderung von URIs verlangsamt das Laden Ihrer Seiten aufgrund des zusätzlichen Serverzugriffs für die Weiterleitung.
Yahoo! bietet eine großartige Diskussion über schnellere/bessere Alternativen zu Weiterleitungen. Ich verwende gerne mod_rewrite.
Sehr interessanter Artikel!
Übrigens, völlig unrelated, aber wie haben Sie Chrome so aussehen lassen? Die erste Mod, die mir wirklich gefällt!
Es ist nicht Chrome. Es ist der Safari-Browser.
Es scheint die Mac-Version von Chrome zu sein. Safaris Tabs sehen etwas anders aus.
Ja, das ist Chrome für Macintosh.
Chrome für Mac hat Ränder um die Schaltflächen. Wenn Sie wissen, wie man sie ausschaltet, sagen Sie es. Es sieht wirklich, wirklich cool aus.
Guter Artikel. Haben Sie Gedanken zu Paginierungs-URLs (blah.com/widgets/blue/page-16 oder blah.com/widgets/blue?page=16 oder so etwas)
Und... was halten Sie von "Order by"-URLs? (z.B. blah.com/widgets/blue?sort=price)
Ich würde dazu neigen, die Paginierung in den Abfrage-String zu setzen (wie blue?page=16), da es sich um einen Ansichtsmodifikator und nicht um ein Objekt handelt (dasselbe gilt für die Order-by-URIs).
Da URIs dauerhaft sein sollen, würde etwas wie blah.com/widgets/blue/page-16 gegen diese Regel verstoßen, da sich der Inhalt der Seite mit dem Hinzufügen neuer blauer Widgets ständig ändern würde. :) Ergibt das Sinn?
Auch verwandt – ich mag Paginierungssysteme wirklich nicht, bei denen die zweite Seite ?page=1 ist. Das kann wirklich nervig werden, besonders wenn man versucht, sich zu einer tieferen Seite „durchzuhacken“ und sich merken muss, dass die Seitenzahl in der URI um eins kleiner ist als die tatsächliche Seitenzahl.
Scheint offensichtlich zu sein, aber es gibt viele Websites, die dieses Schema für URIs verwenden.
Also die Richtlinie
* /list
* /list?page=2
* /list?page=3
* usw.
Auch an dieser Frage interessiert.
Jacob hat mit seiner Antwort recht. Der Grund dafür ist, dass "/widgets/blue" mir sagt, dass ich eine Ressource von blauen Widgets betrachte, während die Abfrage ?page=16 impliziert, dass ich Ihrem Server gesagt habe, mir eine spezifische Untermenge der blauen Widget-Ressourcen zu senden.
Der Grund, warum dies eine gute Praxis ist, liegt darin, dass das HTTP-Protokoll zustandslos ist. Das bedeutet, dass ich beim Zugriff auf eine URI die korrekte Darstellung davon abrufen sollte, unabhängig von anderen Aktionen, die ich auf einer Website durchgeführt habe.
Abfrageparameter in einer URI sollten dem Server mitteilen, wie er eine Ressource zurücksenden soll (z.B. eine spezifische Untermenge). Verwechseln Sie dies jedoch nicht mit dem Zurücksenden einer Darstellung der Ressource (z.B. xml, html oder json), dies bestimmen die HTTP-Accept- und Content-Type-Header.
Großartige Erklärung!
Danke Jacob! Dies ist ein großartiger Artikel über allgemeines Ressourcendesign und eine Einführung in RESTful-Prinzipien. Großartige Arbeit!
Ich habe eine Frage zu URLs mit Verzeichnissen. Ein Kollege sagt, dass man alle Dateien im Stammverzeichnis der Website haben sollte, so dass es so etwas wie http://www.domain.com/kevin anstelle von http://www.domain.com/about/kevin ist.
Sie sagten, dies sei aus SEO-Gründen besser; die Seite rankt im Root besser. Ich habe dazu recherchiert und der allgemeine Konsens scheint zu sein, dass das nicht korrekt ist und dass es keine Rolle spielt, wie viele Verzeichnisse man in der URI hat. Und es macht Sinn, dass es keine Rolle spielen sollte, da Google sich nur um Inhalte kümmert. Ich weiß, dass Google in der Vergangenheit die URLs und deren Formung, wie lange Datenbank-URLs mit & und Zahlen darin und so, beachtet hat.
Was denken Sie darüber? Ich versuche seit Jahren, meinem Chef das beizubringen, aber er hört nicht zu.
Danke!
Kevin
Ich bin definitiv kein Experte, aber soweit ich weiß, sind Schlüsselwörter in URIs für Google sehr wichtig (das mag sich geändert haben, ich weiß es nicht genau). Daher könnte es eine gute Idee sein, eine Seite im Stammverzeichnis zu haben, wenn die Dinge, die davor kommen könnten, für die Seite selbst irrelevant wären.
Auch hier scheint die beste Strategie zu sein, für Inhalt und Benutzerfreundlichkeit zu optimieren, und Google wird Sie gut behandeln.
Im Falle Ihres Beispiels ist /about/kevin besser als /kevin, weil bei /kevin nicht offensichtlich ist, dass es sich um eine Über-Seite handelt. Und die Tatsache, dass es eine Über-Seite ist, ist ein wichtiger Teil der Seite.
Es ist auch nicht hackbar; wohingegen man mit /about/kevin zu /about gehen und erwarten könnte, alle Firmenbiografien zu finden (nur ein Beispiel).
Nun, wenn die URI /pages/about/kevin oder sogar /db/content/pages/about/kevin wäre, dann wäre /about/kevin besser, weil die anderen Informationen für die Seite wirklich nicht wichtig sind.
Nur meine Gedanken, jedenfalls…
Für SEO denken Suchmaschinen, dass eine Seite wichtiger ist, wenn sie sich näher am Root befindet, aber nicht in der physischen Verzeichnisstruktur, sondern in der Navigationsstruktur der Website, die manchmal nicht dieselbe ist. Geben wir ein Beispiel.
Angenommen, Sie haben /about/kevin und /staff/mitarbeiter-des-monats/richard auf Ihrer Website. Von der Startseite aus, wenn Sie auf Kevins Seite zugreifen möchten, müssen Sie zuerst zu /about und von dort zu Kevins Seite gehen. Aber Sie haben einen direkten Link auf der Startseite zu Richards Profilseite. Kevin ist also 2 Seiten tief (in der Navigation) von der Startseite entfernt, während Richard nur eine ist. Suchmaschinen werden Richards Seite als wichtiger als Kevins betrachten.
Außerdem, um Ihre erste Frage zu beantworten, ist es besser, /about/kevin und /about/richard zu haben als /kevin und /richard, weil das Wort "about" Suchmaschinen und auch Menschen einen semantischen Wert bietet.
Ich würde auch weiterhin vorschlagen, bestimmte Elemente in den Abfrageparametern zu behalten. Viele Suchmaschinen mögen keine doppelten Inhalte, daher, wenn sie ?sort=up ?sort=down … sehen. Viele Webmaster-Tools der Top-Anbieter erlauben es Ihnen, bestimmte Abfrageparameter zu entfernen, damit sie in Ihrem Site-Index ignoriert werden können. Das können Sie nicht tun, wenn Sie Ihre Adressen so umschreiben, dass sie wie eine Ordnerstruktur aussehen … es sei denn, Sie entfernen "Ordner" aus dem Index, die wie "/sort/up/" aussehen.
Und ja.. es ist ein Gleichgewicht aus relevantem und Top-Inhalt auf der Website, aber immer noch semantisch. Es ist also gut, in der Nähe des Root zu sein, aber wenn Sie eine tiefe Strukturseite haben, ist es immer noch wichtig, den semantischen Pfad anzuzeigen.
Super Rezension zum URI-Design!!
Großartig!
Das ist großartig, aber es wäre schön, einige echte "technische Details" darüber zu geben, wie man diese URIs erreicht!
Ich weiß, dass htaccess einige davon kann, wie das Entfernen von ".html" oder ".php" und "www".
Aber was ist mit der Änderung einer URI wie
domain.com/portfolio.php?id=24
in
domain.com/portfolio/chris/
?
Ja… Ich hoffe, in naher Zukunft einen technischen Follow-up auf meiner Website zu machen.
Die beste Möglichkeit, portfolio?id in eine saubere URI zu ändern, wäre wahrscheinlich ein benutzerdefiniertes / vorgefertigtes CMS, bei dem der gesamte Traffic an das index.php-Skript weitergeleitet wird, das bestimmt, welcher Inhalt bereitgestellt werden soll.
Sie können dafür auch Apache's Rewrite verwenden, aber Sie sollten vielleicht "id=chris" anstelle von "id=24" verwenden. Es ist einfach, /portfolio/chris zu /portfolio.php?id=chris umzuschreiben, weil dieselben Informationen vorhanden sind. Idealerweise enthalten Ihre sauberen und unsauberen URLs genau dieselben Informationen, und Sie übersetzen einfach deren Form mit Rewrite.
Ab heute werde ich auch URL als URI bezeichnen.
Ich könnte sogar das www. verlieren, da Sie auch damit Recht haben. Es ist Zeitverschwendung.
Daumen hoch, Prost Chris.
Moderne Web-Frameworks wie Django und Rails erschweren die Erstellung von *schlechten* URLs.
Ich bin der leitende Entwickler von Mango, einem dateibasierten Blog-System. Mango macht es einfach, elegante URLs zu erstellen und unterstützt Kurz-URLs "out of the box".
Man könnte einen Beitrag schreiben und ihn als 4=>wordpress-conversion-script.text speichern, wodurch der Beitrag unter /wordpress-conversion-script/ zugänglich wäre, und /4/ würde automatisch zur kanonischen URL weiterleiten.
Das lässt sich auch in WordPress einrichten. Auf unseren WordPress-Seiten verwenden die Blogbeiträge die Permalink-Struktur von example.com/blog/%postid%/%posttitle%/
Diese Struktur hat einige nette Vorteile. Erstens steht die Post-ID an erster Stelle, was es für WordPress einfacher macht, zu erkennen, dass Sie einen Beitrag und keine Seite anfordern.
Zweitens, für eine URI wie example.com/blog/123/some-blog-article/, haben wir den Titel des Artikels in der kanonischen URL, aber das Coole ist, dass ein Link zu example.com/blog/123/ auch den richtigen Inhalt anzeigt. Wir haben in diesem Fall einen eingebauten Link-Shortener.
Cooler Beitrag, Jacob. Ich habe mir für ein kommendes Projekt ziemlich viele Gedanken über URI-Design gemacht.
Ich hatte das schon ziemlich gut herausgefunden, aber ich frage mich, wie es bei komplizierteren Aktionen aussieht.
Zum Beispiel das Bearbeiten eines Elements innerhalb einer Kategorie.
http://myawesomeblog.com/categoryname/postname/edit oder
http://myawesomeblog.com/postname/edit
Vielleicht das Bearbeiten/Löschen vor den Element-Alias setzen?
Flickr hat immer noch eines der coolsten URI-Designschemata überhaupt. Zum Beispiel http://www.flickr.com/photos/username/4846720345/in/contacts/, um die neuesten Aufnahmen Ihrer Kontakte anzuzeigen.
Ich würde empfehlen, sich einer RESTfuleren Art der Interaktion mit Ihren URIs zuzuwenden.
Was ich damit meine, ist, dass Sie stattdessen HTTP-Methoden (GET, POST, PUT, DELETE) verwenden sollten, um mit Ihren Ressourcen zu interagieren.
Diese Praxis läuft auf folgende Muster hinaus:
GET: Eine Ressource vom Server abrufen
POST: Eine Ressource auf dem Server erstellen
PUT: Eine Ressource auf dem Server ändern/bearbeiten/interagieren
DELETE: Eine Ressource vom Server entfernen
also statt
http://myawesomeblog.com/postname/edit
Ich würde empfehlen, die folgende Anfrage vom Client auszuführen
PUT http://myawesomeblog.com/postname/
{...ein Haufen http-Header}
{Der Anfragetext kommt hier hin}
Ich stimme zu, obwohl man eine URI für die eigentliche Bearbeitungsseite benötigt, richtig? Also würde /postname/edit ein HTTP PUT an /postname/update oder so etwas ausführen (so funktioniert Rails).
Hallo Leute,
Ich stimme dem REST-Teil voll und ganz zu, danke.
@jacob ja, Sie haben Recht.
Was ich tun würde, ist, die ursprüngliche URI mit der Aktion zu erweitern, also http://myawesomeblog.com/categoryname/postname/edit. Ich bin mir nicht sicher, ob das der beste Weg ist, aber es scheint die beste Option zu sein.
Ich mag keine Systeme wie Drupal, die /my/clean/uri haben, dann /node/2443/edit für die Bearbeitungsseite. Dafür gibt es allerdings ein Modul… :)
Google sagt, dass die Notwendigkeit einer 3+-stelligen Nummer als Identifier entfällt, wenn man eine Nachrichten-Sitemap hat.
Es ist tatsächlich möglich, alle Anfragen mit gemischter Groß-/Kleinschreibung abzufangen, indem Sie [NC] zu Ihren mod_rewrite-Regeln in .htaccess hinzufügen und dann auf die entsprechende Kleinbuchstaben-URL umleiten.
Cool! Da muss ich für all meine Projekte noch genauer nachforschen.
Ein wirklich toller Beitrag. Ich wusste nicht, dass /about besser ist als die Verwendung von /about-company-name.
Auch der kurze Link ist nett.
Ein Problem, das ich habe, ist /blog/category/
Ich würde lieber nur /blog/interviews etc. verwenden.
Ein weiterer wirklich starker Grund für /about, den ich vergessen hatte zu erwähnen, ist, dass viele Benutzer heutzutage einfach zu /about auf jeder Domain gehen und die About-Seite erwarten. Es schadet nicht, dass es kurz und auf den Punkt gebracht ist.
*Keine Anzeichen der zugrunde liegenden Technologie*
Meine Website besteht nur aus einer Reihe statischer HTML-Dateien. Ich habe gerade ein Skript erstellt, das eine einfache Website für mich generiert. Soll ich die .html-Endung beibehalten oder umschreiben?
Schauen Sie sich den Anfang der Kommentare an, ich habe dieselbe Frage gestellt und eine Antwort erhalten.
Großartiger Artikel über URIs!! Sehr hilfreich und ich stimme Ihren Aussagen voll und ganz zu! :)
Gutes Zeug, obwohl meiner Meinung nach
(a) Es ist besser, auf die "www"-Subdomain zu kanonisieren und von der Root-Domain umzuleiten, anstatt umgekehrt. "www" ist spezifischer und unterscheidet von anderen Diensten/Subdomains, wie "mail", "calendar", "store", etc.
(b) URIs sollten niemals Groß-/Kleinschreibungsabhängig sein, sodass Sie sich keine Sorgen um die Kleinschreibung machen müssen. Ich würde gerne sehen, dass die offizielle Spezifikation aktualisiert wird, um dies widerzuspiegeln.
Ich würde bei beiden das Gegenteil argumentieren.
Das "www" verwirrt Benutzer und ist schwer auszusprechen, und die Annahme, wenn es fehlt, ist, dass Sie vom Web sprechen. Wenn Sie store.domain.com sagen, wissen wir, dass Sie nicht nach www suchen. Und es sind 4 Zeichen weniger in jeder einzelnen URL, die Sie erstellen. Die kollektive Zeit, die www verschwendet hat, beträgt viele, viele Lebenszeiten.
Einige Dateisysteme sind Groß- und Kleinschreibungsabhängig, andere nicht. Alles klein zu schreiben umgeht dies und macht URLs einfacher einzugeben. Wenn Ihre URL /Index.html ist, möchten Sie "Index.html" oder "index.html"? Auf den meisten Webservern sind dies nicht dieselben Dateien.
Das ist ein großartiges Thema, das meiner Meinung nach viele, die Websites erstellen, oft vernachlässigen.
Da Sie es nicht erwähnt haben, möchte ich Tim Berners-Lees Cool URIs don’t change von 1998 als weitere Lektüre vorschlagen.
Sie erwähnen es nicht explizit, aber ich denke, es ist auch wichtig zu beachten: „Keine Anzeichen der zugrunde liegenden Technologie“ gilt auch für Mediendateien, nicht nur für Webseiten. Oder was denken Sie?
Ich stimme Ihrem letzten Kommentar zu, „Keine Anzeichen der zugrunde liegenden Technologie“. Deshalb sind RESTful-Muster eine so großartige Möglichkeit, mit dem Server zu interagieren – alles, was man wissen muss, ist, wie man das HTTP-Protokoll verwendet. Der Server kümmert sich dann darum, welche Darstellung der Client zurückerhalten soll.
Ich stimme Webseiten zu: keine .html, .htm, .php, .aspx… auf Webseiten einfügen.
Aber ich stimme Mediendateitypen oder Mediendateitypen für Usability- und Zugänglichkeitsprobleme nicht zu (wenn ich Ihren Kommentar richtig verstanden habe). Wenn Sie auf ein Nicht-HTML-Dokument verlinken, sollten Sie immer die Erweiterung oder das Dateiformat in die URI aufnehmen. Ich meine, die Verwendung von „http://example.com/annual-report“, um auf dem Server auf „http://example.com/annual-report.pdf“ oder „http://example.com/annual-report.doc“ umzuleiten, ist keine gute Praxis (meiner Meinung nach).
Denken Sie an Leute, die keinen Adobe Reader oder einen .doc-Dateibetrachter installiert haben. Wenn sie den Link ohne Erweiterung sehen, klicken sie darauf und erwarten, eine weitere HTML-Seite zu sehen, erhalten aber stattdessen ein „Datei herunterladen“-Dialogfeld und können die Datei nicht öffnen.
Wenn sie die Dateierweiterung in der URI sehen (in der Statusleiste angezeigt, wenn Sie den Link überfahren), können sie erkennen, dass dieser Link zu einem Dokument führt, das sie nicht öffnen können, und sie werden den Link nicht anklicken.
Denken Sie auch an Personen, die auf mobilen Geräten (sogar Smartphones) surfen, oder an Personen mit Screenreadern, zum Beispiel.
Sie haben hier einen gültigen Punkt. Wenn ich ein Dialogfeld aufpoppen sehe und die Dateierweiterung nicht kenne, werde ich viel vorsichtiger sein, was ich herunterlade (obwohl Browser bei PDF-Dokumenten diese im Allgemeinen anzeigen, anstatt einen Download zu erzwingen).
Einverstanden – die Dateierweiterung sollte in der URI für Medien und Downloads enthalten sein… Ich stimme James zu; wenn ich keine Dateierweiterung sehe, werde ich entweder davon ausgehen, dass (1) die Seite kaputt ist oder (2) der Link zu einer Download-Splash-Seite führte.
Ein weiterer Grund, die Technologie zu verbergen, ist ein zusätzlicher Schritt, um böswilligen Benutzern zu verbergen, was Sie im Backend verwenden. Sicher, sie können immer noch relativ einfach herausfinden, was Sie verwenden, aber es ist ein zusätzlicher Schritt, den sie über einen einfachen Blick hinaus unternehmen müssen, was Sie vor den wirklich Faulen schützt. :)
Die Google News-Anforderung ist nicht unbedingt minderwertig und verursacht keine Probleme. Sie müssen Ihre URI nicht vollständig *ersetzen*.
Alles, was Sie tun müssen, ist (für WordPress) /%post_id%/ irgendwo zu Ihrer Permalink-Struktur hinzuzufügen.
Die von uns betriebene Nachrichtenseite (http://rvanews.com/) wird erfolgreich in Google News aufgenommen, indem die Post-ID an das Ende der URIs angehängt wird.
Wirklich guter Beitrag, Mann!
Ich selbst verwende WordPress-Permalinks mit der folgenden Struktur
/%Beitragsname%/
Das sorgt für schöne und saubere URIs
Es gibt eine ständige Diskussion darüber, dass dieses *besondere Format* eine schlechte Wahl für die WordPress-Leistung ist. Das ist jedoch, was ich hier auf CSS-Tricks verwende, und ich kann nicht sagen, dass es so ein großes Problem ist. Wer weiß, ich habe keine Geschwindigkeitstests oder ähnliches, um irgendetwas zu beweisen.
Siehe oben – /%postid%/%postname%/ ist das, was wir auf unseren Websites verwenden.
yourls.org ist super. Schaut es euch an :P
Toller Beitrag!
Aber ich stimme Ihrer Aussage nicht zu, das www aus einer URI zu entfernen und eine 301-Weiterleitung auf die Nicht-www-Seite zu verwenden.
Es sollte umgekehrt sein.
'www' gibt an, dass die URI eine http-URI ist, genauso wie 'mail.' einen Mailserver oder 'ftp.' einen FTP-Server angibt.
Eine HTTP-Anfrage, die an foo.com gesendet wird, sollte per 301 an http://www.foo.com weitergeleitet werden, da http://www.foo.com der korrekte Server für HTTP ist. Dasselbe gilt für Mail-Anfragen an foo.com, die an mail.foo.com umgeleitet werden.
http spezifiziert, dass die URL eine HTTP-URL ist. Deshalb ist das www redundant. Es verschwendet eine unglaubliche Menge an Zeit und Mühe für die große Mehrheit der Menschheit.
www ist der Name des Webservers, mail ist der Name des Mailservers. Sie können diese beliebig benennen. Ihr Mailserver könnte fred.foo.com sein. Ihr Webserver könnte web.foo.com sein.
Ich stimme allen Ihren Punkten zu, außer dem "Kein WWW". Für einige Websites ist es sinnvoll, es zu entfernen, da es tatsächlich nicht benötigt wird und eine besser aussehende Domain ergibt.
Das Entfernen des "www" macht jedoch viele Domains tatsächlich viel hässlicher. Ich könnte mir nicht vorstellen, dass große Namen wie Yahoo! oder Google das www entfernen, um nicht redundant zu sein. Ich stimme zu, es für Subdomains zu entfernen, aber für die Hauptdomain sieht es viel besser und professioneller aus, das www beizubehalten.
Der Benutzer muss es natürlich nicht eingeben, und Sie müssen es nicht einmal mit dem WWW verknüpfen, wenn Sie nicht möchten. Erzwingen Sie einfach das Hinzufügen mit .htaccess: http://dev.myunv.com/snippets/htaccess/force-www-subdomain/
Hässlich ist subjektiv schlechter. Vier Zeichen weniger ist objektiv besser. Wenn Sie "www." dem Benutzer zeigen, wird er es eingeben. Er weiß nicht, dass es nicht notwendig ist.
Sie werden auch "ww." und "wwww." eingeben.
Das Problem, das ich glaube, ist, dass die Aussage, dass der Hostname nicht benötigt wird, falsch ist. Hostnamen werden von HTTP benötigt. Deren Nichtverwendung kann Probleme mit HTTP verursachen, wie zuvor bei Cookies und SSL erwähnt.
Meine Meinung ist, lassen Sie das www. Sie sagen auch, dass die Leute tippen werden, was Sie ihnen sagen. Ich denke auch, dass dies meiner Erfahrung nach falsch ist. Wenn ich jemandem sage, er soll zu sub.domain.com gehen, tippt er fast immer http://www.sub.domain.com. Testen Sie die Weiterleitung ohne www und leiten Sie dann zum www um. Ich wette (es sei denn, jeder bookmarkt Ihre Seite), dass Sie mehr Weiterleitungen haben werden, wenn Sie das www entfernen, als wenn Sie das www lassen.
Zu lernen, dass das Tippen von „google.com“ zu „www.google.com“ weiterleitet, ist nicht schwer herauszufinden. Wir sollten aufhören, Benutzern nachzugeben, die diese Grundlagen nicht kennen, und es ist ihre Schuld, dass sie es nicht wissen.
Außerdem hat das www. vor einer Website, die ihre Inhalte über Subdomains organisiert, einen riesigen Vorteil, indem es die Homepage von allem anderen unterscheidet. Zumindest meiner Meinung nach.
Hallo Chris,
Kudos für die Zusammenfassung dieses Themas.
Mit freundlichen Grüßen, mtness.
Wunderbar. Denkt daran, Kinder, URL ist, wie man sich auf euch bezieht, URI ist, wo ihr seid!
Zufällig – um sie kurz zu halten, verwende ich anstelle von /images /i, anstelle von /media /m, nicht genau das, was Sie sagen, aber es passt dort hinein.
Toller Beitrag!
Die satzähnliche Struktur scheint eine großartige Idee zu sein!
Wie wäre es mit dem Suffix?
Ist es besser, .../my-article.html zu verwenden
anstatt .../my-article
für Dateityperkennung und auch Caching?
Sie entfernen das ".html" nicht aus den Dateien, sondern nur aus den URLs. Sie verwenden die URL /mein-artikel und verwenden Apache Rewrite, um ".html" hinzuzufügen, und dann ist die Datei /mein-artikel.html das, was der Server zurückgibt. Später möchten Sie möglicherweise das Suffix dieser Datei in ".shtml" oder ".php" ändern, aber die URL bleibt dieselbe.
Ausgezeichneter Artikel, Chris.
Ich habe jedoch noch etwas zu der Aussage "Kein WWW" hinzuzufügen.
Es gab eine Zeit, in der ich unbedingt gegen die Aufnahme von www. in den Domainnamen war, aus all den Gründen, die Sie nennen, aber als ich an größeren Websites arbeitete, konnte ich die Vorteile der Domain-Cookies durch die Aufnahme von www. in der Domain nicht ignorieren.
Das Problem beim Weglassen von www aus einer Domain ist, dass jedes Cookie, das Sie setzen, Ihnen für Anfragen von jeder Subdomain zurückgegeben wird. Wenn Sie also static.domain.com verwenden, um Ihre statischen Inhalte bereitzustellen, und Sie ein Cookie für domain.com setzen, ist static.domain.com keine Cookie-freie Domain mehr.
Alternativ stellt das Setzen eines Cookies für http://www.domain.com sicher, dass Ihr Cookie nur für diese Domain an Sie zurückgegeben wird und static.domain.com Cookie-frei bleibt.
Abgesehen davon liefern die meisten Leute nicht genügend Inhalte, um ein CDN zu benötigen oder dies als Problem zu betrachten, in welchem Fall ich vollkommen zustimme. Es ist hässlich und reduziert die Lesbarkeit. Leider ist dies einer dieser Fälle, in denen es sinnvoll ist, dass die Technologie einen Aspekt des Benutzererlebnisses diktiert: Geben Sie das nur nicht der Backend-Abteilung zu, wenn Sie es vermeiden können ;)
Es ist auch gute Praxis, einen abschließenden Schrägstrich einzufügen, da einige Webserver kontextbezogene URLs und Dateien/Verzeichnisse unterschiedlich behandeln.
Hier gibt es viele gute Ratschläge, aber ich habe das Gefühl, dass vieles davon die persönliche Meinung des Autors ist, die als Tatsache dargestellt wird. Ich bin sehr stark für semantische URLs, und ich habe noch nie daran gedacht, die Erweiterung aus einer statischen HTML-Datei zu entfernen. Tatsächlich habe ich noch nie von JEMANDEM gehört, der das getan hat (weil jeder, der sich mit mod_rewrite gut genug auskennt, um das zu tun, wahrscheinlich nicht viele statische HTML-Seiten erstellt).
Wenn Sie ein CMS verwenden, macht es Sinn, aber es scheint eine Menge Arbeit für sehr wenig Ertrag zu sein, die Erweiterungen einfach willkürlich aus der URL zu entfernen. Die Tatsache, dass Sie andeuten, dass .aspx irgendwie die schlechteste Erweiterung ist, macht ziemlich deutlich, dass zumindest ein Teil davon nur Ihre eigenen Macken sind.
Der WWW-Teil scheint auch etwas fragwürdig. Wenn Sie amazon.com in einen modernen Browser eingeben, wird er es in http://www.amazon.com umwandeln und es zuerst versuchen. Der einzige Vorteil davon wäre also, wenn jemand das vollständige "http://amazon.com" in einen Browser eingegeben hätte, und wer tut das schon?
Ich sage nicht, dass das alles schlecht ist, aber es wird hier so dargestellt, als ob "Wenn Sie es nicht so machen, machen Sie es falsch." Und ich bin mir einfach nicht sicher, ob das stimmt.
> Es gibt hier viele gute Ratschläge, aber ich
> habe das Gefühl, dass vieles davon die persönliche
> Meinung des Autors ist, als Fakt dargestellt.
Das ist Webentwicklung. Wenn Ihnen die hier vorgestellten Ideen nicht gefallen, verwenden Sie sie nicht. Das meiste in der Webentwicklung ist Dogma, keine Tatsache. Es sind Traditionen und Best Practices, die ständig an das sich ändernde Web angepasst werden. Nutzer verwenden URLs heute anders als vor 10 Jahren, und die Nutzer selbst sind anders.
> aber es scheint ein GROSSER Aufwand für
> sehr geringen Nutzen zu sein, die Erweiterungen
> einfach willkürlich aus der URL zu entfernen.
Es ist kein großer Aufwand, und Sie erhalten einen enormen Nutzen. Wenn Sie denken, der Nutzen sei gering, haben Sie es nicht verstanden.
Der ganze Sinn von URLs ist, dass sie sich nicht ändern. Andernfalls könnten wir einfach die IP-Adresse herausgeben. Wenn Sie „.php“ oder „.aspx“ in Ihre URLs setzen, verpflichten Sie sich entweder dazu, für immer PHP oder ASP zu verwenden, oder Sie verpflichten sich dazu, dass sich die URL irgendwann in der Zukunft ändert, was zu einem Desaster führt.
Stellen Sie sich vor, Sie kaufen ein Nokia-Handy und Ihre Telefonnummer ist nokia.555.1212. Sie geben sie all Ihren Freunden. Sie wird zum Synonym für „Grover anrufen“. Sie steht überall in Verzeichnissen und Kontaktlisten. Dann, ein paar Jahre später, möchten Sie ein Motorola-Handy, können aber „nokia“ nicht mehr verwenden, Ihre Nummer muss sich in „motorola.555.1212“ ändern, und jetzt ist Ihre gesamte Geschichte ausgelöscht. Niemand kann Sie anrufen. Eine bessere Methode ist, einfach „555.1212“ über ein System zu leiten, das sich nicht darum kümmert, welches Telefon Sie haben. Dasselbe gilt für das Entfernen von „.aspx“ aus Ihren URLs.
Mittlerweile ist das Web alt genug, dass wir wissen, dass wir Technologien immer wieder ändern werden. Selbst wenn Sie bei ASP bleiben, kommt möglicherweise eine neue Version heraus, die „.aspx2“ verwendet, und Sie möchten diese möglicherweise verwenden, und alle Ihre URLs sind kaputt.
Alle Ihre Analysedaten sind an Ihre URLs angehängt, alle Lesezeichen Ihrer Benutzer, alle auf Sie verweisenden Websites.
URLs umschreiben ist nicht sehr schwer. Es gibt einen Befehl namens Rewrite in den Apache-Server-Direktiven.
Und Sie erleichtern allen Ihren Benutzern die Verwendung Ihrer URLs, was sie auf Twitter und anderen sozialen Netzwerken tun.
Sie möchten dies vielleicht nicht bei einer Live-Site tun, aber bei neuen Sites sollten Sie es unbedingt tun. Auch Kunden mögen saubere URLs (besonders wenn sie ein Redesign hinter sich haben, das alle ihre Links und Analysedaten zerstört hat) und werden Sie als Webentwickler besser einschätzen, wenn Sie ihnen eine Site bauen, die Links wie domain.com/name/of/article hat, die sie selbst dekodieren und eingeben können.
Ihr Argument, Suffixe wegzulassen, hat mich nicht überzeugt (obwohl ich es persönlich der Übersichtlichkeit halber sowieso tun würde). Wenn ich eine Website mit .aspx-Erweiterungen erstellen und später auf PHP umsteigen würde, würde das überhaupt keinen Unterschied machen. Sie können jede beliebige Erweiterung verwenden, mit der entsprechenden Umschreibung. Eine mit PHP laufende Website könnte genauso einfach so konfiguriert werden, dass sie eine .aspx-Erweiterung anzeigt, wie dass sie überhaupt keine Erweiterung hat.
Trotzdem würde ich, wie gesagt, sowieso die sauberen URIs bevorzugen. Nur nicht aus diesem Grund. :)
Entschuldigen Sie den Doppelpost, aber ich wollte noch hinzufügen, dass ich tatsächlich in Situationen geraten bin, in denen ein unerfahrener Benutzer eine Adresse ohne das WWW nicht für bare Münze nimmt. http://amazon.com sieht für viele unerfahrene Benutzer, denen ich begegnet bin, falsch aus.
Ausgezeichnete Zusammenfassung guter Praktiken, „delicious-ed“ und zu einer wöchentlichen Zusammenfassung von Tipps und Tricks hinzugefügt.
Das einzige, womit ich nicht einverstanden war, ist die 'www'-Sache, die, wie ich finde, @greg johnson gut erklärt hat.
Jacob, hervorragende Arbeit an diesem Artikel. Einige wichtige Details werden hier besprochen, danke.
Ich muss jedoch sagen, dass ich mit einigen Ihrer Annahmen bezüglich der Weitergabe von URIs von Person zu Person nicht einverstanden bin. Zum Beispiel sagten Sie
Und später
Im Allgemeinen versuchen Menschen nicht, URIs persönlich zu „beschreiben“, es sei denn, es handelt sich um eine grundlegende Seite wie „Über uns“. Die meisten URIs (selbst die sauberen, die Ihren URI-Designstandards entsprechen) sind persönlich kaum zu vermitteln und kaum zu merken. Das ist einfach nicht die Art, wie Menschen „Links“ an andere weitergeben. In den meisten Fällen werden die Menschen eines von drei Dingen tun.
1) Sie sagen: „Ich schicke dir den Link per SMS/E-Mail“;
2) Sie sagen: „Geh zur Startseite (oder Google) und suche nach [was auch immer]“; oder
3) Sie sagen: „Geh zur Startseite und klicke auf [was auch immer]“
Die einzige Ausnahme wäre etwas sehr Einfaches wie die "Über uns"- oder "Kontakt"-Seite, aber diese sind auf den meisten Websites ohnehin leicht zu finden.
Jedenfalls, danke für die Informationen, die Sie hier bereitgestellt haben. Unabhängig von meiner obigen Meinung denke ich, dass Sie hier eine großartige Arbeit geleistet und einige sehr wichtige Themen zur Diskussion gestellt haben.
Ich muss dem zustimmen. Persönlich sage ich Louis' Nummer 1 oder 3. Hauptsächlich, weil selbst ich mich an die URI nicht erinnern kann, oder ich einfach nicht darauf achte, wo ich mich auf der Website befinde. Ich sage einfach, geh zu whatever.com und klicke auf "Über uns", dort findest du den Typen.
Niemand wird sich mehr als solche Dinge merken.
Auch wenn URL nicht mehr der richtige Begriff sein mag, versuchen Sie mal, einen durchschnittlichen Web-Nutzer nach seiner URI zu fragen. Sie werden einen leeren Blick ernten. Entwickler mögen es wissen, aber der Durchschnitts-Joe nicht. Deshalb werde ich, allen zum Trotz, weiterhin URL sagen!
LANG LEBE DIE URL!
Ich selbst sage im Gespräch normalerweise URL, einfach weil ich es ursprünglich so gelernt habe. Ja, meine Mutter hat diesen Artikel gelesen und gefragt: „Was ist eine URI?“, woraufhin ich ihr erklärte, dass es im Grunde dasselbe wie eine URL sei, was sie verstand.
Vielleicht sind wir schuld daran, dass die Öffentlichkeit den Begriff URI nicht kennt... ich weiß es nicht. Also werde ich versuchen, ihn von jetzt an zu verwenden, in der Hoffnung, meine Umgebung über ein Werkzeug aufzuklären, das sie täglich benutzen.
Aber ich werde wahrscheinlich immer noch in URL abrutschen, wenn ich nicht darüber nachdenke. :)
Ich stimme Ihnen zu… ich sage selten jemandem eine vollständige URI in einem Gespräch. Ich dachte hauptsächlich, dass man danach streben sollte, es möglich zu machen, nicht es tatsächlich zu tun. Eher ein schneller Test für saubere URIs. Ich könnte theoretisch jemandem sagen, er solle zu css-tricks.com/guidelines-for-uri-design gehen, aber ich könnte definitiv nicht jemandem sagen, er solle zu http://www.amazon.com/Designing-Social-Interfaces-Principles-Experience/dp/0596154925/ref=sr_1_1?ie=UTF8&s=books&qid=1280927599&sr_8-1 gehen (übrigens ein gutes Buch).
Ich teile Links normalerweise per E-Mail oder schreibe den Link manchmal auf ein Blatt Papier (Altmodische Methode, schätze ich). In der Papiersituation funktioniert es nur mit gut gestalteten URIs.
Vielen Dank für Ihr Feedback! Es tut mir leid, wenn ich im Artikel nicht klar war.
Oh, ich denke, es war klar, Sie haben gute Arbeit geleistet. Ich glaube nur nicht, dass es aus diesem Grund so wichtig ist, dass eine URI lesbar ist, da die Leute das einfach nicht tun.
Nochmals, großartige Arbeit an diesem Artikel.
WordPress nicht nutzen??
Wie geht das?
Wer daran interessiert ist, eigene Short URLs zu erstellen, findet mein Tutorial hier:
http://sean-o.com/short-URL
Eine gute Quelle für URI-Design ist für mich Flickr.
Sie verwenden ein Muster für einzelne Bilder wie dieses
http://www.flickr.com/photos/%5Buser-name%5D/%5Bpicture-id%5D
anstelle von
http://www.flickr.com/photos/%5Buser-name%5D/%5Bpicture-TITLE%5D
Der Vorteil ist, dass Benutzer den Titel ändern können, ohne die URI zu verlieren.
Obwohl die resultierenden URIs vielleicht nicht so schön sind wie der Blog-Stil (Schlüsselwörter im letzten Teil der URI), entsprechen sie dem Prinzip, permanente URIs zu haben.
Stellen Sie sich vor, jemand gerät wegen des Titels seines Beitrags in rechtliche Schwierigkeiten. Die erzwungene Titeländerung würde auch die URI durcheinanderbringen.
Was halten Sie davon?
Stefan
Ich fand schon immer, dass Flickr dies großartig macht. Ich denke, es sieht immer noch okay aus. Zugegeben, nicht so schön, wie Sie sagten. Aber Sie können Ihre Titel ändern, ohne die URI zu beeinflussen.
Bei Blogs könnte man jedoch argumentieren, hey, ich könnte auch die Kategorie oder das Tag ändern. Daher würde ich auch davon abraten, diese als Permalinks zu verwenden. Ich bleibe immer bei der Veröffentlichungsdatumsstruktur, da diese sich nicht ändert.
Diese endgültige ID ist das, was mich immer wieder irritiert. Titel zur Lesbarkeit oder numerische ID, um die Flexibilität zu ermöglichen, keine Weiterleitungen durchführen zu müssen.
Ich stimme denen zu, die sagen, behaltet den WWW-Teil. Der Cookie-Punkt ist gut, aber selbst ohne ihn finden viele Leute das Fehlen von WWW in einer URI verwirrend. Das sind meist Leute, die das Web schon lange nutzen, aber nicht so häufig und nicht mit großer Erfahrung.
Wie auch immer Sie es machen, es muss besser sein als diese verdammten Websites, die die Domain nicht erkennen, wenn Sie das www *nicht* eingeben. Es gibt immer noch eine überraschende Anzahl davon.
Ich stimme den meisten Ausführungen Ihres Artikels zu. Wo ich mich verfange, und es überrascht mich, dass es noch niemand erwähnt hat, ist Ihre Verwendung von Shortlinks. Sie widersprechen allem, was Sie in Ihrem Artikel vorschlagen.
Wenn Shortlinks das sind, was Benutzer am meisten lesen, und ich würde argumentieren, dass dies aufgrund von sozialen Netzwerken immer häufiger der Fall ist, dann profitieren Benutzer selten von der harten Arbeit, die Sie in Ihre kanonischen URIs gesteckt haben.
Ich glaube nicht, dass die meisten Benutzer URIs tatsächlich lesen, sobald sie in der Adressleiste sind, geschweige denn sie hacken. Dienste wie Twitter und Facebook sind, wie ich glaube, die Orte, an denen Benutzer die URIs am meisten lesen. Shortlinks sind größtenteils unlesbar.
Shortlinks haben keinen anderen Zweck, als die Zeichenanzahl zu reduzieren. Sie werden in engen Situationen benötigt, aber „die Verwendung eines Shortlinks beim Teilen einer URI wird empfohlen“ scheint dem Hauptpunkt Ihres Artikels entgegenzustehen.
Könnten Sie die Begründung für Ihren Vorschlag etwas genauer erklären?
Großartiger Artikel, Design für guten Inhalt und gutes SEO werden folgen, exzellente Theorie, mehr muss darüber geschrieben werden. SEO sollte das Ergebnis einer gut gestalteten Website sein, anstatt ein separates Ziel.
.aspx ist sehr ärgerlich? Mehr als .html, .htm oder, sagen wir, .php oder .jsp? Wie ist die vierbuchstabige .NET-Seiten-Erweiterung ärgerlicher als die anderen serverseitigen Seiten-Erweiterungen? Möchten Sie dies all den .NET-Entwicklern da draußen erklären?
Chris
Nur persönliche Erfahrung mit .NET-Websites… nichts gegen .NET-Entwickler. Die meisten mit .NET betriebenen Websites, die ich besucht habe, haben normalerweise URIs wie http://msdn.microsoft.com/en-us/library/015103yb.aspx oder leiten zumindest zu Default.aspx weiter. (Microsoft ist jedoch im Laufe der Jahre mit URIs besser geworden)
Ich persönlich mag Technologien nicht, die Ihr Produkt „einfärben“… das heißt, man sollte eine Website nicht ansehen und sagen: „Das ist in ASP gebaut“ oder „Ich kann erkennen, dass das eine X-Site ist“. Man sollte also die vollständige Kontrolle über HTML, JS, CSS und URIs für seine Site haben.
Ich habe mich persönlich nicht viel mit ASP.NET beschäftigt, und es mag einfache Wege geben, URIs umzuschreiben… Ich weiß, es ist eine sehr mächtige Sprache.
Also, nichts gegen .NET-Entwickler... .jsp ist normalerweise auch so schlecht (Session-IDs in der URI usw.), und Sie haben Recht, es gibt nichts Schlimmeres an .aspx als an .1234, nur die Tatsache, dass, nach den Seiten, die ich gesehen habe, .aspx normalerweise mit anderen unsauberen Elementen einhergeht.
Ich entschuldige mich, falls meine Kommentare wie ein Angriff auf .NET-Entwickler wirkten.
Sie wirken nicht wie ein Angriff. Ich bin mir nicht sicher, ob ich sagen kann, dass mehr .NET-Seiten .aspx enthalten als PHP .php oder irgendetwas anderes.
Und obwohl man das ganze Suffix ziemlich einfach überwinden könnte, wurde es in der Community nicht wirklich thematisiert. CMS-Systeme, die in .NET geschrieben wurden, haben sich ziemlich alle darum gekümmert, aber für Leute, die mit einer Starter-Site anfingen, haben sie es einfach nie hinterfragt.
Seitdem (besser spät als nie) hat uns Microsoft System.Web.Routing gegeben, das in das System integriert ist und die Dinge super einfach macht (besonders mit MVC). Jedenfalls war es in .NET 3/3.5 verfügbar. Aber es wird in .NET 4 ausgeliefert.
Jedenfalls scheint Microsoft viel zu tun, um sicherzustellen, dass die Leute den Routing-Namespace kennen, und ich glaube, sie haben alle ihre Starter-Sites und Projektvorlagen standardmäßig in 4.0 verwenden lassen, so dass die Leute es hoffentlich sehen und anfangen werden, es zu verwenden.
Hallo Jacob,
Danke für die Antwort (und übrigens für den hilfreichen Artikel, den ich vergessen hatte zu erwähnen).
Sie haben Recht, dass in den frühesten Tagen von .NET die URL-Schreibung ziemlich schlecht war. Sie haben sich schließlich mit den neueren Rewrite-Modulen (http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/) zusammengerauft, das ist also eine gute Sache. Ich denke, das Problem war mehr IIS 6 als alles andere, und IIS7 scheint einen großen Schritt zur Lösung dieses Problems gemacht zu haben.
Ich stimme definitiv zu, dass man die serverseitige Verarbeitung aus der URI eliminieren möchte. Für uns war dies eine größere Herausforderung, da die meisten Blog-Software (wie WordPress usw.) besser für eine Linux/PHP-Umgebung optimiert ist. Hoffentlich wird .NET mehr Fokus darauf legen, URIs einfach umleiten zu können, sowie einige der anderen coolen Funktionen, die ich immer häufiger sehe (und Ihr Artikel berührt sie).
Nochmals vielen Dank,
Chris
Ich versuche es mal. ASPX ist für mich ärgerlich, weil es als Warnung dient, dass die Seite, die ich gleich ansehen werde, wahrscheinlich mit ungültigem und ineffizientem Code überladen ist.
Verstehen Sie mich nicht falsch. Ich denke, ASP.NET ist eine großartige Plattform zum Erstellen echter Anwendungen mit webbasierten Oberflächen, aber viele der Websites und CMS-Systeme, die ich auf ASP.NET basierend gesehen habe, sind einfach grauenhaft.
Das sage ich nach 3,5 Jahren als Senior Consultant, der große webbasierte Softwareprojekte in ASP.NET geleitet hat.
Ich weiß, dass es möglich ist, ASP.NET dazu zu bringen, sauberen Code auszugeben, aber meiner Erfahrung nach ist es eine Seltenheit, ein tatsächliches Beispiel dafür in der Wildnis zu finden.
Ich war immer in der Lage, asp.net dazu zu bringen, ziemlich sauberen Code auszugeben (besonders da man so ziemlich alles an .net ändern konnte). Mein Problem waren immer Webforms und Viewstate. Ich verstand, warum MS Webforms machte (um es Winforms-Entwicklern einfacher zu machen), aber Mann, es war unordentlich. Wieder, mit einem eigenen Handler könnte man auf Winforms verzichten (und das tat ich manchmal auch), aber jetzt haben wir MVC, das vielleicht noch nicht da ist, wo Rails ist. Aber für mich ist es nah dran und sehr schön.
Hallo Kurt,
Sehr wahr: CMS-Systeme, die auf ASP.NET basieren, können sehr begrenzt und problematisch sein, um einfache Aufgaben zu erledigen. Es gibt einfach nicht genug davon und nicht genug Variation/Auswahl an CMS-Plattformen für .NET, scheint es.
Wie John sagt, ist es definitiv möglich, sauberen Code in .NET auszugeben, und es sind eher die unachtsamen oder faulen Entwickler, die nicht einfach eine Zeile wie
zu ihrer web.config-Datei hinzufügen (ähnlich Ihrer .htaccess-Datei für Apache-Leute). Es gibt andere Dinge, die sie tun können, aber das hilft, viel saubereren Code auszugeben.
Ja, Viewstate ist für die meisten Anwendungen irgendwie Mist, kann aber ausgeschaltet werden.
MVC scheint sicherlich die Zukunft zu sein, aber ich könnte zu Rails wechseln, anstatt zu versuchen, das zu lernen.
Chris
Ich fand MVC sehr einfach zu erlernen. Ich habe mir auch Rails angesehen. Es gefällt mir sehr gut, aber Ruby ist dort mein Hauptproblem. Es war für mich einfacher, .NET MVC zu erlernen als Rails, einfach weil meine Rails-Fähigkeiten bestenfalls nicht existent sind.
Jedenfalls finde ich beide großartig. Ich habe gehört, dass die Performance von Rails manchmal außer Kontrolle geraten kann. Und aus kommerzieller Sicht gefällt mir, dass .NET kompiliert ist.
Die Ruby-Community scheint jedoch freundlicher zu sein als die .NET-Community. Hilfsbereiter meine ich. .NET-Leute scheinen gerne über einen hinwegzureden, wenn man eine Frage stellt.
WordPress nicht nutzen, wie geht das?
Das ist offensichtlich off topic, aber wie haben Sie die rahmenlosen Schaltflächen in Chrome erhalten!?
Vielleicht sollten Sie auf dieser Seite nach »chrome« suchen, und Sie werden die Antwort finden.
Taggart
Website optimiert für viele Hilfen. Richtige Studie.
Das ist offensichtlich abseits des Themas, aber wie haben Sie die rahmenlosen Schaltflächen in Chrome erhalten?
Vielen Dank für Ihre sehr hilfreiche und freundliche Anleitung, ich habe eine Übersetzung ins Russische veröffentlicht (http://legco.net/entry-382.php), wenn es Ihnen nichts ausmacht