coding style - validate - ¿Cuáles son los parámetros de url convención de nomenclatura o estándares a seguir?
w3c standards list (6)
¿Existen convenciones de nomenclatura o estándares para que se sigan los parámetros de la URL? Generalmente utilizo camel caseing como userId o itemNumber. Como estoy a punto de comenzar un nuevo proyecto, estaba buscando si hay algo para esto, y no pude encontrar nada. No estoy viendo esto desde una perspectiva de lenguaje o marco, sino más bien como un estándar web general.
Al igual que las otras respuestas, no escuché ninguna convención.
El único "estándar" al que me adheriría es utilizar la práctica más amigable con los motores de búsqueda de usar un reescritor de URL.
El estándar para URI está definido por RFC2396 .
Cualquier cosa que quede después de la parte estandarizada de la URL se le deja a usted.
Probablemente solo quiera seguir una convención particular sobre sus parámetros en función del marco que use.
La mayoría de las veces ni siquiera te importa porque no están bajo tu control, pero cuando lo hacen, probablemente quieras ser consistente y tratar de generar bits fáciles de usar:
- que son cortos,
- si deben ser accesibles directamente para los usuarios, deberían ser fáciles de recordar,
- distingue entre mayúsculas y minúsculas (puede ser difícil según el sistema operativo del servidor).
- siga algunas pautas de SEO y mejores prácticas , pueden ayudarlo mucho.
Diría que la limpieza y la facilidad de uso son objetivos loables a los que debemos aspirar cuando presentamos las URL.
hace un trabajo bastante bueno.
No hay estándares que yo sepa. Solo tenga en cuenta el límite de longitud de URL de IE de 2.083 caracteres.
No hay normas que yo sepa, y el caso no debería importar.
Sin embargo, dentro de su aplicación (sitio web), debe apegarse a sus propios estándares. Por tu propia cordura si nada más.
Recomiendo leer No cambiar, de Cool URI, de Tim Berners-Lee, para obtener una idea de esta pregunta. Si está utilizando parámetros en su URI, podría ser mejor reescribirlos para reflejar lo que realmente significan los datos.
Entonces, en lugar de tener lo siguiente:
/index.jsp?isbn=1234567890
/author-details.jsp?isbn=1234567890
/related.jsp?isbn=1234567890
Tendrías
/isbn/1234567890/index
/isbn/1234567890/author-details
/isbn/1234567890/related
Crea una estructura de datos más obvia, y significa que si cambia la arquitectura de la plataforma, los URI no cambian. Sin la estructura anterior,
/index.jsp?isbn=1234567890
se convierte
/index.aspx?isbn=1234567890
lo que significa que todos los enlaces en su sitio ahora están rotos.
En general, solo debe usar cadenas de consulta cuando el usuario pueda esperar razonablemente que se generen los datos que están recuperando, por ejemplo, con una búsqueda. Si está utilizando una cadena de consulta para recuperar un recurso inmutable de una base de datos, utilice la reescritura de URL.
Yo uso minúsculas Dependiendo de la tecnología que utilice, QS se amenaza con mayúsculas y minúsculas (por ejemplo, PHP) o no (por ejemplo, ASP). Usar minúsculas evita posibles confusiones.