La documentación oficial de Django y otros tutoriales en la web siempre usan una barra inclinada al final de la URL. ex:
url(r'^accounts/login/', views.login) # login view in turn calls login.html # instead of url(r'^accounts/login', views.login) Dado que las accounts son el directorio y el inicio de login (login.html) es el archivo, ¿no deberíamos usar una segunda URL? Esto también hará que los parámetros GET se vean más estructurados:
accounts/login?name='abc' # login is a file that is accepting parameters vs. accounts/login/?name='abc' # login directory (maybe index) is accepting parameters??Una de las filosofías de diseño centrales de Django es que las URL deben ser hermosas.
Por lo tanto, algunas direcciones URL como accounts/detail?name='abc' deben asignarse como accounts/detail/abc/ . Puede capturarlo usando expresiones regulares en las configuraciones de su URL. Aquí la URL es bastante ordenada y fácil de usar. Esto ayudará a los motores de búsqueda a indexar correctamente tus páginas (ahora puedes olvidarte de rel=canonical ) y ayudará en el seo.
Ahora, el motivo de una barra diagonal final, considere una vista (en cualquier marco) que resuelva relativamente about.html para un usuario en la ruta, users/awesomeUser
dado users/awesomeUser y users/awesomeUser/ son diferentes,
Si el usuario está en users/awesomeUser , el navegador lo resolverá como users/about.html porque no hay una barra inclinada final que no queremos
Si el usuario está en users/awesomeUser/ , el navegador lo resolverá como users/awesomeUser/about.html porque hay una barra inclinada al final
childrelativo afamily/parent/esfamily/parent/child.childrelativo afamily/parentesfamily/child.
Técnicamente, foo.com/bar y foo.com/bar/ son dos URL diferentes, y los robots de los motores de búsqueda (y algunas herramientas de análisis de tráfico web) las tratarían como páginas separadas. Django debería hacer un esfuerzo por "normalizar" las URL para que los robots de los motores de búsqueda no se confundan.
Este es el razonamiento detrás de la configuración de APPEND_SLASH. (APPEND_SLASH le permite forzar la adición de barras a una URL)
user/awesomeUser y user/awesomeUser/ . No puede hacer que los métodos POST/PUT/PATCH/DELETE funcionen con rest_framework a menos que defina explícitamente APPEND_SLASH=False en la configuración y trailing_slash=False para todos y cada uno de los enrutadores que debe usar (si usa enrutadores). Es como si básicamente te saltases esto la mayoría de las veces y tuvieras que perder mucho tiempo depurándolo. Django recomienda append slashes y no lo fuerza.
Depende del desarrollador agregar barras o no.
De los documentos para el middleware que usa APPEND_SLASH
un indexador de motor de búsqueda los trataría como URL separadas, por lo que es una buena práctica normalizar las URL.
Django no lo requiere, solo intenta ayudar a su SEO sugiriendo una forma estándar de hacer URL.
Sí, sé que la barra inclinada no tiene nada que ver con este middleware, pero esta es la mejor explicación que pude encontrar sobre una posible razón.
Esto ayuda a definir la estructura de su sitio web. Aunque django puede admitir cualquier cosa ingresada después del dominio que se pasa al servidor, hacerlo de esta manera le permite agregar fácilmente "subpáginas" a la URL sin que parezca accounts/loginreset?id=alkfjahgouasfjvn25jk1k25
Habiendo dicho eso en el caso anterior, puede tener sentido dejarlo fuera.