Esta es una publicación invitada de Jacob Gillespie, quien inició un interesante hilo en Forrst sobre este tema. Lo invité a publicarlo aquí, a lo que aceptó gentilmente.
Durante los últimos años, me he interesado por la usabilidad y el diseño web. Una de las áreas que parece que a menudo se pasa por alto cuando se trata del diseño de un sitio es el diseño de los URI en ese sitio. Los sistemas CMS modernos permiten diversos grados de personalización de URI, pero los valores predeterminados a menudo no son tan utilizables como podrían ser, y los URI a menudo se colocan en último lugar en el proceso de diseño.
Los URI limpios son un componente de un sitio web limpio y es importante. La mayoría del acceso de los usuarios finales a Internet implica un URI y, independientemente de que el usuario ingrese el URI o no, está trabajando con uno de todos modos.
Primero, me gustaría hablar sobre los principios rectores detrás del diseño de URI, luego hablar sobre la implementación práctica de los principios.
Nota: Originalmente, escribí el borrador de este artículo usando el término “URL”, pero dado que “URL” ha sido desaprobado en su mayoría por “URI”, lo actualicé para usar el término URI. Más información de W3C.
Principios
Primero, echemos un vistazo a algunos de los principios generales del diseño de URI.
Un URI debe representar un objeto, de forma única y permanente
Una de las filosofías más fundamentales detrás de un URI es que representa un objeto de datos en Internet. El URI debe ser único para que coincida uno a uno: un URI por cada objeto de datos.
Si bien este es siempre el objetivo, hay momentos en los que es muy difícil o imposible de lograr. Las etiquetas de URL canónicas se inventaron para ayudar a reducir la cantidad de contenido duplicado visto por un motor de búsqueda. Si bien no es una solución final, se recomiendan encarecidamente las URL canónicas, ya que los grandes motores de búsqueda como Google ahora les prestan atención. Para obtener más información sobre las URL canónicas, consulte este artículo de SEOmoz.
Los URI también deben ser permanentes (es decir, elija el URI una vez y déjelo así). Esto habla de un buen diseño de URI antes de que se lance un sitio, y los URI se planifican cuidadosamente. Llegará un momento en el que desee realizar mejoras en sus opciones o, de lo contrario, deberá cambiar la estructura de URI. Cuando esto se convierta en una necesidad, asegúrese de configurar redirecciones HTTP 301 movidas permanentemente en su servidor. Esto le dice a los navegadores y motores de búsqueda la nueva ubicación del contenido y también preservará cualquier PageRank que el antiguo URI haya acumulado.
Sea lo más amigable posible con los humanos
Este es el factor impulsor más fundamental detrás del diseño de URI (o debería serlo). Los URI deben diseñarse pensando en el usuario final. La optimización de motores de búsqueda (SEO) y la facilidad de desarrollo deben ocupar un segundo lugar.
Una forma de mantener un URI fácil de usar es hacerlo breve y directo. Esto significa usar la menor cantidad de caracteres posible y al mismo tiempo mantener la usabilidad. Entonces, / about es mejor que / about-acme-corp-page. Si bien se esfuerza por ser lo más breve posible, no debe sacrificar esa facilidad de uso al usar URI como / 13d2, ya que esto no tiene ningún significado para los usuarios finales.
Por el contrario, se recomienda el uso de un enlace corto siempre que se comparta un URI. Esto es ideal para twittear enlaces en Twitter o para compartir en sitios sociales como Facebook o Google Buzz. Es genial si puedes controlar tu propio acortador de URI por razones de SEO, aunque un sitio como Bit.ly también es bueno. Yo personalmente uso PrettyLink Pro (un complemento de WordPress) para crear mis URI cortos. Una alternativa es el complemento de URL corta.
WordPress proporciona un botón para obtener un enlace corto a una publicación basada en el formato /? P = XXX de WordPress, que probablemente sea más corto que la estructura de enlace permanente elegida. La ventaja es que funcionará mientras su sitio esté disponible. La desventaja es que la brevedad del enlace depende de la longitud de su nombre de dominio.
El URI no debe depender de información que no sea importante para el contenido o el usuario. Un ejemplo común de esto es usar el ID de la base de datos como URI, como en / products / 23. Al usuario final no le importa que el producto sea el registro de la base de datos número 23, por lo que una URI como / products / ballpoint-pen es mucho mejor. Puede ser tentador recurrir a una estructura de URI tan pobre, ya que a menudo es más fácil en el backend consultar la base de datos con una ID en lugar de tener que buscar un alias para encontrar el objeto.
Una buena prueba para ver si un URI es un URI fácil de usar es la prueba “amigable para el habla”. Debería poder mencionar un URI en una conversación con un amigo, y debería tener sentido. Por ejemplo:
Mi biografía está en el dominio punto com slash jim
en vez de
Mi biografía está en el dominio punto com barra diagonal barra gg 2 3
Consistencia
Los URI de un sitio deben tener un formato coherente. Una vez que elija su estructura de URI, sea coherente y sígala. Tener una buena estructura de URI para una parte del sitio significa que todavía tiene una estructura deficiente en general. Para que un usuario confíe en que los URI funcionan de cierta manera en un sitio, el formato debe ser coherente. Si debe cambiar de estructura (tal vez esté actualizando un sitio mal diseñado), use redireccionamientos 301 como se mencionó anteriormente.
URI “pirateadas”
En relación con la coherencia, las URI deben estructurarse de modo que sean inteligibles “pirateadas” o modificables. Por ejemplo, si / events / 2010/01 muestra un calendario mensual con eventos de enero de 2010, entonces:
- / events / 2009/01 debería mostrar un calendario de eventos para enero de 2009
- / events / 2010 debe mostrar los eventos de todo el año 2010
- / events / 2010/01/21 debe mostrar los eventos del 21 de enero de 2010
Palabras clave
El URI debe estar compuesto por palabras clave que sean importantes para el contenido de la página. Entonces, si el URI es para una publicación de blog que tiene un título largo, solo las palabras importantes para el contenido de la página deben estar en el URI. Por ejemplo, si la publicación del blog es “Mi viaje a Best Buy para tarjetas de memoria”, entonces el URI podría ser / posts / 2010/07/02 / trip-best-buy-memory-cards o algo similar.
Como beneficio adicional, el uso de palabras clave importantes en la URI mejorará el SEO. Mi filosofía personal de SEO es que, en lugar de optimizar para los motores de búsqueda, optimiza para obtener un buen contenido. Los motores de búsqueda se han fijado el objetivo de encontrar el mejor contenido en la web, por lo que hacer todo lo posible para crear un sitio fácil de usar con excelente contenido y oportunidades para obtener más información (enlaces) dará, en mi opinión, el mejor resultado. -resultados a plazo para la visibilidad del motor de búsqueda.
Detalles técnicos
Hemos cubierto algunos de los principios rectores detrás del diseño de URI. Ahora, veamos algunas implementaciones técnicas de esas pautas.
Sin evidencia de la tecnología subyacente
El URI no debe tener .html, .htm, .aspx (una gran molestia) o cualquier otra cosa adjunta que solo esté diseñada para mostrar la tecnología subyacente. A ningún usuario final le importa que su sitio esté escrito en ASP.NET (.aspx), ColdFusion (.cfm) o que utilice Server Side Include (.shtml), o al menos la mayoría de los usuarios finales no lo hacen. La información adicional es solo escritura adicional y espacio adicional para errores y frustraciones.
La única excepción a esta regla es agregar un URI con un sufijo como .atom, .rss o .json para solicitar que se devuelva el formato determinado. Alternativamente, el formato podría solicitarse con el encabezado Accept HTTP.
No WWW
El www. debe eliminarse del URI del sitio web, ya que es una escritura innecesaria y viola las reglas de ser lo más amigable posible para los humanos y no incluir información innecesaria en el URI.
Sin embargo, muchos usuarios seguirán escribiendo www. prefijo, por lo que www.domain.com debería redirigir 301 a domain.com. Lo mismo ocurre con la redirección 301 de www.subdominio.dominio.com a subdominio.dominio.com.
Formato
Los URI deben tener el formato:
dominio.com/[key information]/[name]/?[modifiers]
La información clave es información que no es el identificador del objeto (como el título de la publicación), pero sigue siendo clave para el objeto al que se accede. Esto puede incluir:
- el tipo de cosa (es decir, publicaciones)
- la categoría principal general (es decir, tecnología)
- miembros de datos clave (es decir, la fecha de publicación)
Los modificadores modifican la vista, no el modelo de datos que se está representando y, por lo tanto, son parte de la cadena de consulta y no el URI en sí.
La cantidad de “información clave” debe mantenerse al mínimo, ya que los URI no deben estar demasiado anidados. Cada elemento colocado en la sección de información clave debe ser realmente clave para acceder a la página.
Al final, el URI debería representar una jerarquía descendente. Por ejemplo
- dominio
- escribe
- categoría
- título
Ejemplo: http://domain.com/posts/servers/nginx-ubuntu-10.04. En el caso de elementos con fechas, el formato debe seguir la jerarquía descendente:
- año
- mes
- día
Ejemplo: http://domain.com/news/tech/2007/11/05/google-announces-android.
Google News tiene algunos requisitos interesantes para las páginas web que desean aparecer en los resultados de Google News: Google requiere al menos un número único de 3 dígitos. Debido al hecho de que ignorarán los números que parecen años, se prefiere un número de 5 o más dígitos. También se recomienda un mapa del sitio de Google News. Este es uno de esos casos en los que si absolutamente debe apuntar a Google News, debe ajustarse a esta estructura de URI inferior. Pero, si es necesario, asegúrese de que sea coherente y de que aún se pueda piratear (por ejemplo, utilice el formato aaaammdd como 20100701).
Todo en minúsculas
Todos los caracteres deben estar en minúsculas. Intentar describir un URI a alguien cuando se trata de un caso mixto es casi imposible.
Si alguien escribe el URI en mayúsculas y minúsculas, debería ser redirigido 301 a la página en minúsculas. Eso suena muy bien, pero en la práctica, no estoy exactamente seguro de si eso es posible … usar un CMS que reescriba todas las solicitudes en un solo archivo sería la forma más fácil de lograrlo, ya que el script podría emitir el 301 en minúsculas, pero No estoy seguro de si hay una forma más fácil (reglas .htaccess o algo así).
Acciones adjuntas al URI
Las acciones se pueden agregar al URI, como mostrar, eliminar, editar, etc. Las acciones no destructivas (aquellas que no cambian el objeto) deben solicitarse con un HTTP GET, mientras que las acciones destructivas deben enviarse al URI. Ejecute una búsqueda en Google de REST URI Design para obtener más información.
Los identificadores de URI deben ser compatibles con URI
Un URI puede contener el título de una publicación y ese título puede contener caracteres que no son compatibles con URI. Por lo tanto, el título de la publicación debe ser compatible con URI. Por ejemplo
- Todos los caracteres en mayúscula se hacen en minúsculas
- Los caracteres como é deben convertirse en e (etc.)
- Los espacios deben reemplazarse por guiones
- Los caracteres desconocidos (!, @, #, $,%, ^, &, *, Etc.) deben reemplazarse por un guion
- Los guiones dobles (-) deben reemplazarse por un solo guión
- Probablemente me estoy olvidando de más reglas
Los caracteres pueden tener un URI de escape (como% 20 para el carácter de espacio), pero esto generalmente es una mala idea por muchas de las razones anteriores (muestra tecnología, escritura innecesaria, etc.)
Idea divertida
Use una estructura similar a una oración (crédito para Chris Shiflett):
chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done
Si conoce más pautas de URI que me perdí o tiene algún comentario sobre las que sí recordaba, ¡me encantaría escucharlas!
Creditos
Muchas gracias a la primera comunidad que vio los borradores iniciales (muy) de esta publicación y contribuyó con muchos comentarios interesantes. Un agradecimiento especial a @chriscoyier, @caludio, @steerpike y @mattthehoople por contribuir directamente a la lista de pautas y a todos los demás comentaristas de Forrst por brindar una discusión útil.
¡Gracias a mi papá por corregir y revisar! ¡Gracias también a Chris por tener la amabilidad de ofrecerse a publicar esto en CSS Tricks!