¿Debo usar el caso del título en las URL?


9

Actualmente estamos decidiendo una convención de nomenclatura consistente en un sitio con múltiples aplicaciones web. Históricamente, he sido un defensor de las "letras minúsculas". al crear URL:

http://example.com/mysystem/account/view/1551

Sin embargo, en el último año o dos, específicamente desde que comencé a usar ASP.NET MVC y tuve más tratos con las URL basadas en REST, me he convertido en un fanático de poner en mayúscula la primera letra de cada sección / palabra dentro de la URL, ya que lo hace Más fácil de leer (en mi humilde opinión).

http://example.com/MySystem/Account/View/1551

No estamos en una situación en la que las personas necesiten leer o comprender las URL, por lo que ese no es un controlador per se. Lo principal que buscamos es un enfoque consistente que sea racional y tenga sentido.

¿Hay algún estándar que declare que es bueno hacerlo de una forma u otra, o problemas con los que nos podemos encontrar en configuraciones (al menos realistas y modernas) que elegirían una preferencia sobre otra? ¿Cuál es el consenso general para este debate actualmente?

Respuestas:


10

Como la elección es principalmente cosmética (es decir, la mayoría de los sistemas no diferencian entre mayúsculas y minúsculas, y los usuarios ciertamente no lo hacen), entonces sugeriría simplemente elegir lo que lo haga feliz. La consistencia dentro de la aplicación es la clave , no la manera que elijas.

Como está utilizando ASP.Net, le recomiendo seguir el enfoque PascalCase, ya que eso es lo que tiende a existir dentro del marco de Microsoft (bibliotecas del sistema, etc.) Pero no hay "mejores prácticas" aparte de ser coherente.

La mayoría de los navegadores hacen un trabajo bastante bueno al ocultar la URL del usuario, hasta el punto de que muchas personas que tienen Google como su página de inicio, buscarán Facebook y harán clic en él, en lugar de ingresar la URL de Facebook en su navegador.


77
Sin embargo, el sistema hace diferenciar ...
ghoppe

1
Al menos debe mencionar que la distinción entre mayúsculas y minúsculas depende de la configuración del servidor, por lo que vale la pena considerarla, en lugar de indicar incorrectamente que el sistema no diferencia entre mayúsculas y minúsculas.
jleach

@ jdl134679 hecho.
TZHX

4

Para los sitios web internos, no importa tanto como sea coherente con él.

Para sitios externos, públicos, es probable que desee quedarse con minúsculas, que es más o menos el estándar en el alojamiento web Linux / Apache. Según recuerdo, algunas versiones de Firefox también parecen manejar la carcasa de URL de manera diferente que IE. Esto también podría aplicarse a Chrome también.

Tener una carcasa consistente también es importante para la optimización de motores de búsqueda. No desea que Google vea lower-case.aspx y Lower-Case.aspx como páginas diferentes con contenido duplicado. Si bien sus algoritmos intentan evitar esta identidad equivocada, sucede de vez en cuando y puede hacer que se penalice una página.


2

Mientras los usuarios puedan escribirlo como quieran, realmente no importa. Personalmente, prefiero TitleCase, pero hay muchos que no están de acuerdo. Si eres consistente, a nadie le importará.

Si su servidor web no puede, por alguna razón, mostrarme http://foo.com/HelloWorldcuando intento acceder http://foo.com/helloworld, debe optar por todo en minúsculas. Si bien las personas rara vez escriben URL completas en estos días, las direcciones de frente deben ser accesibles sin tener que jugar con las mayúsculas.


2

Que comenzó a usar MVC no debe "filtrarse" en su abstracción REST. Hay buenas razones para usar todas las URL en minúsculas con guiones entre palabras. Los URI (no los nombres de dominio) SON sensibles a mayúsculas y minúsculas. Si minúsculas todo y utiliza guiones para separar las palabras, ha eliminado muchas conjeturas y excepciones, y si utiliza un servidor proxy (nginx, nodejs, apache ...) no tendrá todo comenzar a romperse porque de repente es sensible a mayúsculas y minúsculas.

"NOMBRES MiXeD-CaSe. No confunda a sus usuarios mezclando mayúsculas y minúsculas en la URL. Adhiérase a letras minúsculas y no las haga adivinar. Si su usuario realmente escribe una URL en mayúsculas y minúsculas, normalícela en el servidor y sirva el caso apropiado ".


1

Mientras TLD no distinguen entre mayúsculas y minúsculas y rutas de Windows utilizan una combinación de capital y el caso de Pascal, nuestras aplicaciones son sensibles a los caminos solicitud entrante, donde los caminos, o componentes de la misma, por lo general normalizaron a un caso estándar, ya que /format/JSON/y /format/json/son solicitudes de dos diferentes formatos y referencia dos recursos distintos.

Cada vez que he visto http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/ , sentí que la intención del desarrollador era principalmente parecer un poco diferente del resto, pero no es nada innovar y tampoco ayuda a mejorar la legibilidad, especialmente ahora que tiene I y l , O y 0 , otras letras que compiten por su análisis.

No conozco ningún consenso, tampoco creo que debería haber uno, porque algo tan simple como poner en mayúscula ciertas partes de una URL podría tener un impacto positivo en la legibilidad y estoy seguro de que alguien, en algún lugar, ya está surgiendo con ideas interesantes a la hora de aplicar mayúsculas y minúsculas a las URL.

Pero, a juzgar por el hecho de que la mayoría de los servidores web se ejecutan en Linux y que los desarrolladores siempre terminamos estandarizando los datos de texto entrantes porque la entrada distingue entre mayúsculas y minúsculas, me estoy aferrando a cómo se ha hecho todo el tiempo.


0

¡NUNCA use el caso del título por razones de usabilidad! ¡Imagínese cuánto tiempo debe dedicar y clics para realizar diferentes URL de casos en su teléfono MÓVIL !


Aunque en mi iPhone, el caso del título requiere menos pulsaciones de teclas adicionales que '-' o '_'.
BradS

Los teléfonos inteligentes modernos, al menos los teléfonos con Windows permiten deslizar desde la tecla de mayúsculas para lograr esto en un solo deslizamiento
0fnt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.