Freundliches Url-Schema?

Question

Eines der vielen Dinge, die mir in den letzten Jahren gefehlt haben Abstreifservice die ich letzte Woche eingerichtet habe, sind hübsche URLs. Im Moment wird der Benutzerparameter an das Skript übergeben mit ?u= was ein Symptom für einen faulen Hacker ist (was das Skript zugegebenermaßen ist). Ich habe jedoch darüber nachgedacht, es zu überarbeiten, und ich würde gerne ein paar Rückmeldungen zu den verfügbaren Optionen erhalten. Im Moment gibt es zwei Seiten, Update und Chart, die dem Benutzer Informationen liefern. Hier sind die beiden Möglichkeiten, die ich mir überlegt habe. "1234" ist die Nummer der Benutzer-ID. Der Nutzername kann aus technischen Gründen leider nicht verwendet werden:

• http://< tld >/update/1234
• http://< tld >/chart/1234

oder

• http://< tld >/1234/update
• http://< tld >/1234/chart

Option 1 ist der Aufruf von update mit der Benutzer-ID. Option 2 ist die Bereitstellung eines Verbs zur Bearbeitung einer Benutzer-ID.

Was ist unter dem Gesichtspunkt der Konsistenz sinnvoller?

---

Eine weitere erwähnte Option ist

• http://< tld >/user/1234/update
• http://< tld >/user/1234/chart

Dies bietet Platz für Seiten, die sich nicht auf einen bestimmten Benutzer beziehen, d.h.

• http://< tld >/stats

Answer 1

Wenn Sie sich für dieses Schema entscheiden, können Sie ganz einfach verhindern, dass (wohlerzogene) Robots Ihre Website ausspionieren:

 http://< tld >/update/1234
 http://< tld >/chart/1234

Dies liegt daran, dass Sie eine /robots.txt-Datei einrichten können, die Folgendes enthält:

 Disallow /update/
 Disallow /chart/

Für mich ist das ein schöner Bonus, der oft übersehen wird.

Answer 2

Option 1 entspricht den gängigen ASP.NET MVC-Beispielen. Einige der Beispiele unter Modell Ansicht Controller Modell haben die Form {controller}/{action}/{id}. Die .NET 3.5 Schnellstart zum Thema Routing enthält eine Tabelle mit einigen gültigen Routenmustern:

Definition der Route -- Beispiel einer passenden URL

{controller}/{action}/{id} -- /Produkte/show/getränke

{table}/Details.aspx -- /Produkte/Details.aspx

blog/{action}/{entry} -- /blog/show/123

{Berichtstyp}/{Jahr}/{Monat}/{Tag} -- /Umsätze/2008/1/5

{locale}/{action}
-- /de-US/show

{Sprache}-{Land}/{Aktion}
-- /de-US/show

Answer 3

Ich wäre vorsichtig geneigt, mit der Userid zu beginnen - Option 2 -, da die Verzeichnisstruktur (das, was davon existiert) zwei verschiedene Funktionen über die Daten eines Benutzers ist. Es ist das Diagramm des Benutzers und die Aktualisierung durch den Benutzer.

Das ist allerdings ein ziemlich unbedeutender Punkt, ohne zu wissen, ob es Pläne für eine signifikante Erweiterung des Funktionsumfangs dieses Geräts gibt.

• Wird es in Zukunft nur noch die Zusatzfunktionen foo und bar und baz für einzelne Benutzer geben? Wenn ja, wird Option #2 aus dem oben genannten Grund attraktiver - die userid ist die Kerndaten, es macht irgendwie Sinn, mit ihr semantisch zu beginnen.
• Werden Sie nicht-benutzergesteuerte Funktionen hinzufügen? Dann könnte es sinnvoll sein, mit einem Kopfverzeichnis zu beginnen - /user/1234/update, /user/1234/chart, /question/45678/activity, /question/45678/stats usw.

Answer 4

Ich persönlich mag diesen Stil, weil er den Benutzer nicht verändert, aber Ihnen einen spezifischen Einblick in ihn gibt.

• http://< tld >/1234/update
• http://< tld >/1234/chart

Wenn Sie den umgekehrten Weg gehen, würde ich erwarten, dass Sie alles unter /update oder /chart sehen und dann nach Benutzer eingrenzen können.

Answer 5

Entscheiden Sie sich für Letzteres; URLs sollen hierarchisch sein (oder zumindest werden sie von den Benutzern in Analogie zu lokalen Verzeichnispfaden so gelesen). Der Schwerpunkt liegt hier auf verschiedenen Ansichten eines bestimmten Benutzers, daher ist "Benutzer" das allgemeinere Konzept und sollte an erster Stelle stehen.