Proporcionar URL amigables para un sitio web versus realidades de ID de bases de datos

24

Tenemos una base de datos de recursos, ya sean productos, publicaciones de blog o algo así. Necesitamos diseñar un esquema de URL para abordarlos, para el sitio web público.

Aquí hay dos ejemplos vinculados con ID de base de datos:

Aquí hay un ejemplo que es amigable:

http://en.wikipedia.org/wiki/LED_circuit

(Un pequeño vistazo a mi vida de navegación allí)

Me gustan las URL amigables ya que tienes una idea sobre lo que está al final de la URL cuando pasas el mouse por encima o la ves en un correo electrónico o documento. Es mejor para SEO, o solía ser.

¿Qué sucede cuando se cambia el nombre del documento o producto? Ya sea porque cambió (es posible que Wiki no cambie pero nuestros recursos sí) o por un error tipográfico, ¿verdad? Nuestros recursos son muy técnicos, largas palabras y propensos a errores.

Además, tenemos una ID de base de datos, que es un número. Veamos una idea para la dirección de un video usando una tienda de alquiler simulada:

http://vidsyeah.com/video/sliding-doors/287171

El ID es obvio y se usa en la búsqueda de DB. Multa.

El bit de puertas correderas no es único y solo se generó a partir del título del video, podría verificarse en GET, por lo que si se ingresaron puertas deslizantes y no coinciden con lo que realmente está en el documento 287171, responde 404.

O tal vez podría ignorarse, permitiendo que los humanos peguen lo que quieran allí, si a alguien le importa. Entonces esta URL también funcionaría:

http://vidsyeah.com/video/anything-at_all/287171

El problema con la verificación de la parte amigable es, como se mencionó, el problema del cambio de nombre o la corrección de errores tipográficos. Si el nombre cambió, y en nuestro dominio eso sucede, no queremos romper las URL que existen, así que deberíamos:

Simplemente no verificar la parte amigable.
Verifique, pero agregue un 'historial' de partes amigables al registro de la base de datos para que cualquier ID amigable anterior siga funcionando.

Tus pensamientos e ideas son bienvenidas.

Luke

— Luke Puplett
fuente

11

incluso este mismo sitio usa una combinación http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(usando una versión no verificada a la luz de los cambios en el título, también el enlace más corto "compartir" es solo la identificación: http://programmers.stackexchange.com/q/255684/25768(y la identificación del usuario para el seguimiento de la insignia)

— ratchet freak

11

Si tiene una identificación única en su URL, no veo por qué desea verificar la parte de la babosa. Úselo para las miradas e ignórelo para las búsquedas.

— thorsten müller

Si alguno de ustedes quiere dar una respuesta adecuada, votaré para que obtengan los puntos. Dejaré que lleguen los votos y otorgaré la respuesta a los más votados en un par de días.

— Luke Puplett

1

programmers.stackexchange.com/questions/231483/…

— mosquito

3

Nunca conocí el término babosa antes. Debo haber estado debajo de una roca. Geddit?

— Luke Puplett

6

Mantener la ID en la URL es el método más a prueba de futuro y, como lo demostró, las URL aún pueden verse relativamente bien.

Otra opción utilizada por múltiples proyectos es mantener un historial de las babosas utilizadas anteriormente. Cuando cambia el título, actualiza la babosa y, si alguien intenta buscar una babosa obsoleta, busque en la lista de babosas antiguas. De esa manera, las babosas viejas se pueden reutilizar para contenido nuevo (o no dependiendo de su implementación).

Wordpress hizo eso y también lo hizo la gema friendly_id que es probablemente la gema más utilizada para administrar identificadores amigables para Rails.

Además, aunque me gustan las URL atractivas, creo que es importante recordar que es muy probable que sea una característica utilizada por usuarios más expertos en tecnología. Algunos navegadores incluso comienzan a ocultar URL (o parte de ella).

— mbillard
fuente

2

Esta historia de babosas es lo que estaba considerando. Desde que publiqué la pregunta, he notado que muchos sitios con nombres importantes tienen una babosa que no está marcada, puede modificarla para decir algo. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 funciona. StackExchange es inteligente ya que 'corrige' y redirige el navegador para garantizar que se muestre y se comparta el enlace correcto.

— Luke Puplett el

Un "slug" es menos útil para las personas y más útil para la optimización del motor de búsqueda, ya que un "slug" o "URL amigable" debe tener palabras clave relacionadas con el contenido de la página. Los usuarios avanzados no son la razón para incluir URL amigables en su sitio. Las clasificaciones de los motores de búsqueda tienden a ser la razón principal.

— Greg Burghardt

Estoy en desacuerdo. Es difícil trabajar con URL con solo ID; es difícil recordar de una lista de ellos a cuál querrás volver. O si va a haber algo inapropiado en el otro extremo del enlace. La barra de direcciones de Chrome también sugiere cualquier parte de la URL, lo cual es útil.

— Luke Puplett

1

@LukePuplett sí, creo que la forma en que SE trata con las URL es la más fácil cuando se trata de babosas.

— mbillard

@GregBurghardt la única diferencia está en el porcentaje de clics, los usuarios tienden a hacer clic un poco más en URL amigables: stackoverflow.com/questions/505793/…

— mbillard

3

He usado dos escenarios diferentes en el pasado.

/id/some-slugdonde la idse utiliza para las operaciones de búsqueda , la babosa no. Por lo tanto, la babosa puede ser cualquier cosa . Pero, cuando el slug no coincide con el slug real, el usuario es redirigido a la versión actual.
/permalinkpara los casos en que no queríamos una identificación en la url o donde la url nunca debería cambiar, aunque haya una identificación disponible (consulte [1] y [2] ). Por supuesto, en este caso el permalinkse utiliza para las operaciones de búsqueda . Tanto la babosa actual como el enlace permanente (la primera babosa) se almacenan en la base de datos.

De ninguna de estas maneras necesita mantener un historial de babosas en su base de datos, lo que se volvería problemático muy pronto.

ps: en el segundo caso, necesitarás algunas rutas muy específicas para mantener los créditos sociales:

si lo desea, redirija a los usuarios a la URL actual (sin enlace permanente)
tener el enlace permanente utilizado como la URL en los botones sociales
siempre redirige el rastreador de Facebook al enlace permanente

Ver [1] y [2] nuevamente.

— Veta
fuente

¿Por qué será problemático? Si guardo y la identificación y la babosa son algo, el visitante irá a la página real. ¿Será perjudicial para el SEO?

— Jnanaranjan

¿Te refieres a mantener un historial de babosas? ¿Qué haces cuando alguien quiere reutilizar esa babosa? ¿Para la misma u otra identificación? ¿Cómo diseñas la base de datos y / o el código para evitar múltiples redirecciones? ¿Desea ocultar la existencia después de la eliminación y los redireccionamientos exponen la existencia anterior? Todo esto no es imposible, pero plantea todo tipo de preguntas que prefiero evitar por diseño.

— Lode

Lo que quería decir es que si el ID está presente en la URL, no importa cuál sea el slug, será redirigido a la página solicitada. Entonces la historia de las babosas no importa. Sin embargo, estoy de acuerdo en que es problemático para Android.

— Jnanaranjan

1

Ah bien. Eso es lo que agregué un escenario 1 ¿verdad? ¿O quieres decir algo más?

— Lode

Sí. Eso es correcto.

— Jnanaranjan

2

¿Qué sucede cuando se cambia el nombre del documento o producto?

La respuesta HTTP 301 (movida) se diseñó para este propósito. Si algún cliente va al URI anterior, simplemente envíele el nuevo URI y pueden redirigirlo.

El bit de puertas correderas no es único y solo se generó a partir del título del video, podría verificarse en GET, por lo que si se ingresaron puertas deslizantes y no coinciden con lo que realmente está en el documento 287171, responde 404.

Si sigo correctamente, este es un trabajo duplicado, tiene un identificador de nombre para el recurso y una identificación en el mismo URI. Eso no sirve para nada.

Si le preocupa que varias películas tengan el mismo nombre, puede agregar información adicional sobre la película en la URL

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

o

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

Una vez dicho esto, no hay nada de malo en usar ID si eso tiene sentido para su modelo de datos, particularmente si lo único por lo que se está agrupando es que son videos.

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

El cliente, ya sea una computadora o un usuario humano, no debería depender demasiado de la estructura de URI en primer lugar, deberían estar mirando el contenido que ha devuelto para averiguar qué recurso encontrar.

No hay nada de malo en tener un sistema URI sensible que facilite a alguien adivinar la ubicación de un recurso o navegar hacia arriba y hacia abajo en la estructura en función de las propiedades compartidas (es decir, todas las películas en 2004), pero su sistema no debe confiar en eso y ningún cliente debería romperse si cambia sus URI

O para decirlo de otra manera, deberías poder cambiar durante la noche de

http://vidsyeah.com/video/studios/paramount/sliding_doors

a

http://vidsyeah.com/video/12323

y ningún cliente debería interrumpirse porque los clientes deberían mirar contenido, no URL.

— Cormac Mulhall
fuente

Al igual que la respuesta de Jon, creo que no estás usando tu sombrero UX cuando piensas en esto. Quiero aumentar la usabilidad de la dirección. Vea mi comentario en la pregunta: "Me gustan las URL amigables ya que tiene una idea sobre lo que está al final de la URL cuando pasa el cursor o lo ve en un correo electrónico o documento. Es mejor para SEO, o solía ser".

— Luke Puplett el

2

Para lanzar un 301, necesitaría poder buscar el recurso correcto, por lo tanto, necesitaría un historial.

— Luke Puplett el

1

Necesitaría un historial, pero si tiene un sitio con recursos que cambian, es una buena idea de todos modos.

— Cormac Mulhall

No hay problema con los URI amigables. No haría el esquema de que el URI puede ser cualquier cosa pero seguir funcionando si tiene una ID al final. Eso realmente no resuelve ningún problema (el usuario aún debe recordar la ID) e introduce un esquema de URI confuso (el usuario podría legítimamente preguntar por qué dos URI diferentes, uno con un error de ortografía, van al mismo recurso)

— Cormac Mulhall

1

Si le preocupan los errores ortográficos en los URI, una forma común de lidiar con esto es los URI sugeridos en la página de error 404 para la URL mal escrita. Puede hacer una búsqueda de patrones de palabras y devolver lo que cree que el usuario podría estar buscando.

— Cormac Mulhall

1

La BBC usa babosas que son:

alfanumérico (para compacidad)
único (para búsquedas)
no secuencial (para que el orden en que se agregan las cosas a la base de datos no esté expuesto)

por ejemplo, http://www.bbc.co.uk/programmes/b006mk7h

Cada programa público tiene una identificación y una babosa. Las ID pueden ser enteros de incremento automático, como de costumbre, y los huecos no están expuestos.

— Nicholas Shanks
fuente

0

Desde un punto de vista RESTful, los URI deben seguir una estructura jerárquica predecible y perphaps para mejorar la usabilidad.

Esto los hará más fáciles de usar por los consumidores. Si sus datos tienen relaciones, entonces sería necesario algún tipo de jerarquía.

Parece que el esquema es: \video\[name]\[id]

Si el nombre no se utiliza para ninguna clasificación adicional, se podría descartar a favor de \video\[id].

Sin embargo, si desea clasificar los videos, tal vez el nombre sea útil.

Ejemplos:

\ video \ Puertas batientes \ 123
\ video \ Puertas batientes \ 124
\ video \ Puertas correderas \ 125
\ video \ Puertas correderas \ 126

Es realmente una decisión de diseño sobre cómo se modela el acceso.

— Jon Raynor
fuente

Creo que está pensando en esto desde un punto de vista de arquitectura de información de API / sitio. Estaba buscando introducir una parte de URL amigable generada para ayudar a los humanos y al SEO. Aparentemente esto es algo común y se conoce con el nombre de 'slug'. El nombre no se usa para la clasificación y se agrega (no se elimina) para mejorar la experiencia de usuario con la URL y nuestro sitio / marca.

— Luke Puplett