Ich arbeite tatsächlich in einem Django-Projekt und bin mir nicht sicher, welches Format für die URL am besten geeignet ist, um auf eine bestimmte Objektseite zuzugreifen.
Ich habe über diese Alternativen nachgedacht:
%Vor%Dies ist der einfachste und bekannteste Weg, dies zu tun. "id_object" ist die Autoincremental-ID, die vom Datenbankmodul beim Speichern des Objekts generiert wird. Das Problem, das ich auf diese Weise finde, ist, dass die URLs einfach iterierbar sind. So können wir ein einfaches Skript erstellen und alle Seiten besuchen, indem wir die ID in der URL erhöhen. Vielleicht ein Sicherheitsproblem.
%Vor%Die "hash_id" sollte ein alphanumerischer Zeichenfolgenwert sein, der zum Beispiel mit UUID-Funktionen erzeugt wird. Es ist eine gute Idee, weil es nicht iterierbar ist. Aber generieren "zufällige" uniques IDs können einige Probleme verursachen.
%Vor%Django enthält ein "slug" -Feld für Modelle und kann verwendet werden, um ein Objekt in der URL zu identifizieren. Das Problem, das ich in diesem Fall finde, ist, dass der Slug sich in der Zeit ändern kann, was zu defekten URLs führt. Wenn eine Suchmaschine wie Google diese fehlerhafte URL indiziert hat, können Nutzer zu "nicht gefundenen" Seiten geführt werden und unser Seitenrang kann sinken. Einfrieren der Slug kann eine Lösung sein. Ich meine, speichern Sie den Slug nur bei "Add" -Aktion und nicht bei "Update". Aber die Schnecke kann jetzt etwas Altes oder Falsches darstellen.
Alle Optionen haben Vor- und Nachteile. Kann eine Kombination aus ihnen einige Probleme haben. Was denkst du darüber?
Ich denke, die beste Option ist dies:
%Vor%Warum?
Erster Grund: Die AUTOINCREMENT_ID ist für die Benutzer einfach, um ein Objekt zu identifizieren. Zum Beispiel, in einer E-Commerce-Website, wenn der Benutzer mehrmals die Seite besuchen möchte (weil er nicht sicher ist, das Produkt zu kaufen) wird er die URL erkennen.
Zweiter Grund: Das Slug-Feld verhindert das Problem, dass jemand über die Webseite iteriert und macht die URL für die Leute klarer.
Dieser .com/object/10/ford-munstang-2010 ist klarer als .com/object/c30204225d8311e185c3002219f52617
IDs sind nicht streng "iterierbar". Dinge werden gelöscht, hinzugefügt, usw. Im Laufe der Zeit gibt es sehr selten eine lineare lineare Entwicklung von IDs von 1-1000. Aus Sicherheitsgründen spielt es keine Rolle. Wenn Ansichten aus irgendeinem Grund geschützt werden müssen, verwenden Sie Logins und zeigen nur an, was jeder Benutzer für jeden Benutzer sehen darf.
Bei jedem Ansatz gibt es Vor- und Nachteile, aber ich halte Schnecken für die beste Option. Sie sind deskriptiv, sie helfen den Nutzern zu erkennen, wo sie sich befinden und auf einen Blick können sie erkennen, wohin sie gehen, wenn sie auf eine URL klicken. Und die Schattenseiten (404, wenn sich Schnecken ändern) können gemildert werden, indem 1) die Schnecken nicht verändert werden, 2) die richtigen Umleitungen eingerichtet werden, wenn ein Schneckenstein aus irgendeinem Grund geändert werden muss. Django hat sogar ein Redirects-Framework eingebaut, um das noch einfacher zu machen.
Die Idee, eine id und eine Schnecke zu kombinieren, ist einfach verrückt von wo ich sitze. Sie verlassen sich immer noch entweder auf die ID oder auf den Slug-Teil der URL. Es ist also nicht anders, nur das eine oder das andere zu verwenden. Oder Sie verlassen sich auf beides und verschärfen Ihre Probleme und führen zusätzliche Fehlerquellen ein. Die Verwendung von beiden bietet einfach keinen sinnvollen Nutzen und scheint nichts anderes als eine gute Möglichkeit, Kopfschmerzen zu verursachen.
Tags und Links django url identifier