Dynamiczne adresy URL - z ukośnikiem lub bez niego?

Question

Krótkie pytanie brzmi: jaka jest najlepsza praktyka, aby używać ukośnika końcowego w adresach URL lub nie.

Istnieje wiele artykułów: this, this, this.

Jednak wszystkie wydają się zajmować statyczną strukturą katalogów. A co z dynamicznymi adresami URL, takimi jak te, które zostały przepisane, lub tymi obsługiwanymi przez centralny obiekt (na przykład framework sieciowy), które przesyłają do zasobów wewnętrznych w zależności od konwencji/konfiguracji. Dla nich nie jest już tak, że serwer internetowy faktycznie wyszukuje i oblicza dokładne lokalizacje - to tylko kwestia analizy.

Tak więc, na przykład z wiosny MVC zadeklarować, że dana metoda klasy jest wywoływana gdy URI mecze /service/action/{pathParam} - dla tego adresu URL, imo, to nie ma sensu mieć ukośnik - żądanie jest obsługiwane przez jednego i za każdym razem ten sam serwlet, który robi parsowanie.

Uważam, że należy być konsekwentnym - używać wszędzie ukośnych ukośników lub nie używać ich wcale.

Więc:

• jaka jest najlepsza praktyka - z, bez, lub cokolwiek, po prostu być spójne
• jaki jest powód, aby wybrać jeden nad drugim

Answer 1

• najważniejsze: pozostań niezmieniony - 1 URL == 1 strona
• Przekieruj jedną (niewłaściwą) do drugiej (prawa) poprzez przekierowanie HTTP 301
• następnie ponownie, jeśli masz stronę internetową, na której pracują różne osoby: nie używaj ukośnych ukośników.

W idealnym świecie ludzie po prostu kopiują & wkleją adres URL, gdy chcą połączyć się z twoimi rzeczami. Niestety nie żyjemy w idealnym świecie. ludzie (programiści, marketing) mają skłonność do pisania adresów URL (nie pytajcie mnie dlaczego, po prostu robią ....), a potem znów mają tendencję do zapominania o końcowym ukośniku na końcu.

nieprawidłowe adresy URL w linkach zewnętrznych są niższe, jeśli nie masz ukośnych ukośników.

ale w przypadku większości witryn nie ma znaczenia. wybierz jeden, trzymaj się go.