Existen convenciones de nomenclatura o estándares para los parámetros Url que se deben seguir. 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.¿Cuáles son los parámetros de url convención de nomenclatura o estándares a seguir
Recomiendo leer Cool URI's Don't Change por Tim Berners-Lee para tener 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.
Así que 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
Se crea una estructura de datos más evidentes, y significa que si cambia la arquitectura de la plataforma, de su URI Don no cambias Sin la estructura anterior,
/index.jsp?isbn=1234567890
convierte
/index.aspx?isbn=1234567890
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á recuperando, p. Ej. 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.
Esto no responde la pregunta en absoluto. La publicación original preguntaba si había una convención de nomenclatura para los parámetros de cadena de consulta. Como mencionó usted mismo, las cadenas de consulta son apropiadas cuando busca o filtra los datos (http://stackoverflow.com/a/17999251/1424734), entonces, ¿por qué la tangente en su uso correcto? – jstol
No hay normas que yo sepa. Solo recuerda el URL length limit de IE de 2.083 caracteres.
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 utilizar un reescritor de URL.
No hay normas que yo sepa, y el caso no debería importar.
Sin embargo, dentro de su aplicación (sitio web), debe seguir sus propios estándares. Por tu propia cordura si nada más.
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.
Las normas para URI están definidas por RFC2396.
Cualquier cosa que quede después de la parte estandarizada de la URL se le deja a usted.
Probablemente solo desee seguir una convención particular sobre sus parámetros en función del marco que utilice.
mayoría de las veces que ni siquiera realmente se preocupan porque estos no están bajo su control, pero cuando lo hacen, es probable que quieren al menos ser coherente y tratar de generar trozos fáciles de usar:
Yo diría que la limpieza y la facilidad de uso son objetivos loables a los que debemos aspirar al presentar las URL.
StackOverflow hace un buen trabajo.
Estoy de acuerdo con usted en el estilo de las URL, y evitando los parámetros, estaba interesado en este estilo primero cuando vi que Jira y Bamboo de Atlassians lo tenían, hacía que el aspecto de las URL fuera simple. En Apache, se puede configurar con algunas reglas de reescritura. ¿Sabe algo similar para IIS y .NET –
De acuerdo con [RFC 3986, 6.2.2.1] (http://www.ietf.org/rfc/rfc3986.txt): * se supone que otros componentes de sintaxis genéricos son sensible*. Entonces, ¿por qué generar bits insensibles a mayúsculas y minúsculas? –
@MartijnBurger porque un usuario final que ingresa manualmente la URL puede no esperar que una cadena distinga entre mayúsculas y minúsculas. Principio de la menor sorpresa y todo. –
La tendencia general es eliminar detalles de la tecnología de la URL, como '.php'. Además, las personas crean todo tipo de estructuras de URL "semánticas". No importa mucho. – usr