¿Cuáles son los beneficios deBeneficios de la URL REST
http://www.example.com/app/servlet/cat1/cat2/item
URL
sobre
http://www.example.com/app/servlet?catid=12345
URL
¿Podría haber algún problema si usamos primer URL porque al principio nos estaban usando la primera URL y cambian a la segunda URL. Esto está en el contexto de un gran contenido que cambia constantemente en el sitio web. Aquí las categorías pueden ser infinitas en número.
Una diferencia es que la segunda URL no nombra las categorías, por lo que el código del cliente y los usuarios humanos deben buscar primero un nombre de categoría a la página de asignación de números, almacenar esas asignaciones, usarlas todo el tiempo y actualice la lista cuando se encuentren categorías previamente desconocidas, etc. Dado que la primera URL necesariamente conoce las categorías, incluso si la página del artículo no las menciona (pero el sitio aún puede necesitar una lista de categorías en algún lugar).
Otra diferencia es que el primer formato codifica dos niveles de categorización, mientras que el segundo oculta el número de niveles. Eso puede hacer que las cosas sean más fáciles o más difíciles según la variable que quiera que sea la profundidad (ahora o más adelante) y si alguien vincula incorrectamente el código a una profundidad de 2 niveles (por ejemplo, analizando las URL con una expresión regular capturando las categorías usando dos subgrupos) Por supuesto, podría existir el mismo problema si se combinan con la profundidad actual de las categorías enumeradas en una página de asignación id-> category-path de todos modos ...
En términos de SEO, si esto es algo que desea indizar por los motores de búsqueda the first is better assuming the category names are descriptive of the content debajo de ellos. La mayoría de los motores favorecen las URL que coinciden con la consulta de búsqueda. Sin embargo, si los nombres de categorías pueden cambiar, es probable que necesite mantener 301 redirects cuando lo hagan.
El primer formulario estará mejor indexado por los motores de búsqueda, y es más compatible con la caché. Esto último es a la vez una ventaja (puede disminuir la carga en su servidor) y una desventaja (no necesariamente es consciente de que las personas vuelven a visitar su página, y los cambios de página pueden no propagarse inmediatamente a los usuarios: debe tenerse un poco de cuidado). tomado para lograr esto).
El primer formulario también requiere (algo) procesamiento más pesado para obtener el elemento deseado de la URL.
Si usted puede controlar la sintaxis URL, sugeriría algo así como:
http://www.example.com/app/servlet/cat1/cat2/item/12345
o mejor aún, a través de reescritura de URL,
http://www.example.com/cat1/cat2/item/12345
donde 12345 es el ID de recurso. Luego, cuando acceda a los datos (que de todos modos lo habría hecho), podrá hacerlo rápidamente; y simplemente verifica que el registro no concuerde con cat1, cat2 y item. Experimenta con la configuración del caché de la página y asegúrate de enviar el ETag (¿quizás basado en el ID?) Y los encabezados Last-Modified, así como comprobar las solicitudes de encabezado If-Modified-Since y If-None-Match.
Lo que tenemos aquí no es una cuestión de indexación "mejor" sino de relevancia.
Por lo tanto, 1st URL marcará su página como más relevante para el tema (asumiendo la correlación entre el nombre de la página/gato y el tema).
Por ejemplo: digamos que los dos queremos clasificar por "zapatos de Red Nike", digamos (por simplicidad) que ambos obtuvimos el mismo "puntaje" en todos los factores de SEO, excepto en el URL. En 1er caso, la URL puede ser http://www.example.com/app/servlet/shoes/nike/red-nice y en la segunda http://www.example.com/app/servlet?itemid=12345.
Simplemente mirando ambas cuerdas, puede intuitivamente sentir cuál es más relevante ... La primera le dice por adelantado "Diablos, sí, yo soy todo acerca de los zapatos rojos de Nike", mientras que la segunda murmura un poco "¿Zapatos rojos de Nike? ¿Te refieres al código del artículo 12345?"
Además, tener una parte de KW en la URL lo ayudará a obtener más relevancia y también puede ayudarlo a alcanzar objetivos "largos" sin mucho trabajo. (Con solo tener KW en la URL a veces puede ser suficiente)
Pero el problema es aún más profundo. El segundo tipo de URL incluye parámetros y esos pueden (un 99.9% lo harán) generar problemas de contenido duplicado. Cuando use parámetros, tendrá que tratar con preguntas como:
y etc
Así que ¿por qué elegir la segunda versión? Porque alguna vez simplemente no tienes elección ... :)
En relación con una aplicación RESTful, no deberías preocuparte por la plantilla URL. El "mejor" es el que es más fácil de generar para la aplicación.
En relación con la indexación y el SEO, lo siento, pero es poco probable que los motores de búsqueda entiendan su API de hipermedia para poder indexarla.
Para obtener una mejor comprensión en cuanto a las direcciones URL, echar un vistazo a:
Hola, Tony, Gracias por su respuesta, ¿podría ver ningún problema en utilizando 1st URL si estamos cambiando de 2nd URL a first URL. Y si tenemos un número infinito de categorías. – user965884