ruby-on-rails - instalar - devise tutorial rails
¿Cuál es mejor para un sitio de rails?/{login} o/usuario/{login} (5)
Que es mejor (para el usuario, para la longevidad, para el rendimiento, para lo que sea) tener:
http: // {site} / {login} ej. http://wildobs.com/adam_jack
o
http: // {sitio} / usuario / {login}
Pros de ex:
- El usuario se siente más especial.
- Las URL son más cortas.
Contras de ex:
- No puede haber usuarios con inicios de sesión que coincidan con las palabras clave, y las palabras clave probablemente crezcan con el tiempo.
Claramente, esto es importante para hacerlo bien (o equivocarse y atenerse) ya que todas las URL definidas por el usuario se basan en él. Cambiarlo parecería un suicidio en el sitio.
¿Los inconvenientes (especialmente a lo largo del tiempo) superan a los profesionales?
Hay un problema muy importante que permite a los usuarios crear nombres arbitrarios en la raíz del servidor web (como podrían elegir su propio inicio de sesión si usas / {login} en lugar de / user / {login}): algunos nombres tienen un significado mágico especial, y estos significados son definidos por terceros . Por ejemplo:
- robots.txt , también conocido como el "estándar de exclusión de Robots", seguido de todos los motores de búsqueda de buen comportamiento.
- favicon.ico , que comenzó como un estándar de Internet Explorer y luego fue adoptado por muchos otros navegadores.
- Algunos sitios web (al menos Google y IIRC Yahoo) usan el hecho de que puedes crear un archivo con nombre especial en la raíz del servidor web como prueba de que eres el webmaster del sitio y así poder acceder a algunas funciones adicionales (como Google Webmaster Tools).
Hay varios otros; He oído hablar de mapas de sitios y archivos que permiten el acceso extra a través del dominio, pero no hay forma de que yo (o cualquier otra persona) pueda conocerlos a todos.
Personalmente iría por / usuario / {login}
Usar / {login} se parece demasiado a llenar el espacio de nombres global, y todos sabemos que los globales son malos;)
Puede considerar una tercera opción:
Delimitar usuarios con un solo carácter, en lugar de un directorio, como en Unix.
http: // sitio / ~ nombre de usuario
Esto incluso puede dar como resultado una modificación a / usuario / nombre de usuario si es más conveniente.
Luego tiene nombres cortos, es fácil de tratar, y ninguna de sus páginas regulares usará ese carácter especial.
-Adán
Yo diría que los contras superan a los profesionales, así que ve con / user / login over / login. Considera , ya que también es MVC: creo que es más fácil programar sabiendo que todo en / user / blah siempre se referirá a un usuario, mientras que si no lo haces tendrás que considerar todas las posibilidades.
Por ejemplo, en sitio / foo, foo podría ser un nombre de usuario, página de administración u otra palabra clave. Es mucho más fácil tratarlo si segmentas correctamente todo para que sepas si ves el sitio / usuario / foo siempre es un usuario llamado foo.
Desde un MVC RESTful, la última vez que verifiqué el ejemplo del complemento Restful Authentication es el patrón de creación de la sesión. Entonces, en lugar de ingresar en un usuario, está creando una sesión para el usuario. En ese caso, GET http://{site}/session/new mostraría la pantalla de inicio de sesión y POST http://{site}/session con los parámetros correctos registraría al usuario si la autenticación es exitosa.
Luego, si lo desea, puede crear una nueva ruta para http://{site}/login que redirigiría a http://{site}/session/new . Del mismo modo, DELETE http://{site}/session te desconectaría.