Esistono convenzioni di denominazione o standard per i parametri Url da seguire. Generalmente uso l'involucro del cammello come userId o itemNumber. Mentre sto per iniziare un nuovo progetto, stavo cercando se c'è qualcosa per questo, e non ho trovato nulla. Non sto guardando questo da una prospettiva di linguaggio o framework, ma più come uno standard web generale.Quali sono le convenzioni di denominazione dei parametri url da seguire
Raccomando di leggere Cool URI's Don't Change di Tim Berners-Lee per una panoramica di questa domanda. Se stai usando i parametri nel tuo URI, potrebbe essere meglio riscriverli per riflettere cosa significhi effettivamente i dati.
Così, invece di avere la seguente:
/index.jsp?isbn=1234567890
/author-details.jsp?isbn=1234567890
/related.jsp?isbn=1234567890
Avresti
/isbn/1234567890/index
/isbn/1234567890/author-details
/isbn/1234567890/related
Si crea una struttura dati più evidente, e significa che se si cambia l'architettura della piattaforma, del vostro URI don cambiare. Senza la struttura di cui sopra,
/index.jsp?isbn=1234567890
diventa
/index.aspx?isbn=1234567890
che significa che tutti i link sul vostro sito sono ora rotti.
In generale, è necessario utilizzare solo stringhe di query quando l'utente può ragionevolmente aspettarsi che i dati che stanno recuperando vengano generati, ad es. con una ricerca. Se si sta utilizzando una stringa di query per recuperare una risorsa non modificata da un database, utilizzare la riscrittura dell'URL.
Questo non risponde affatto alla domanda. Il post originale chiedeva se esistesse una convenzione di denominazione per i parametri della stringa di query. Come hai detto tu stesso, le stringhe di query sono appropriate quando stai cercando o filtrando i dati (http://stackoverflow.com/a/17999251/1424734), quindi perché la tangente al loro corretto utilizzo? – jstol
Non ci sono standard di cui sono a conoscenza. Ricordati di IE URL length limit di 2.083 caratteri.
Come le altre risposte, non ho sentito parlare di alcuna convenzione.
L'unico "standard" che vorrei rispettare è quello di utilizzare la pratica più amichevole dei motori di ricerca di utilizzare un rewriter URL.
Non ci sono standard che io conosca e il caso non dovrebbe avere importanza.
Tuttavia, all'interno dell'applicazione (sito Web), è necessario attenersi ai propri standard. Per la tua sanità mentale se non altro.
Io uso lettere minuscole. A seconda della tecnologia che si utilizza, QS viene minacciato come maiuscole e minuscole (ad esempio PHP) o meno (ad esempio ASP). L'uso di lettere minuscole evita possibili confusioni.
Standard per URI sono definiti da RFC2396.
Qualsiasi cosa dopo la parte standardizzata dell'URL è lasciata a voi.
Probabilmente si desidera solo seguire una particolare convenzione sui parametri in base al framework che si utilizza.
Il più delle volte non si sarebbe nemmeno realmente a cuore, perché questi non sono sotto il vostro controllo, ma quando lo sono, probabilmente vuole almeno essere coerenti e cercare di generare user-friendly bit:
Direi che la pulizia e la facilità d'uso sono obiettivi lodevoli da perseguire quando si presentano gli URL.
StackOverflow fa un buon lavoro.
Sono d'accordo con te sullo stile degli URL, ed evitando i parametri, ero interessato a questo stile quando ho visto che Jira e Bamboo di Atlassians ce l'hanno, ha reso l'aspetto di url semplice. Su Apache può essere impostato con alcune regole di riscrittura. Sai qualcosa di simile per IIS e .NET –
Secondo [RFC 3986, 6.2.2.1] (http://www.ietf.org/rfc/rfc3986.txt): * si presume che altri componenti generici di sintassi siano case- sensibile*. Quindi, perché generare bit senza distinzione tra maiuscole e minuscole? –
@MartijnBurger perché un utente finale che immette manualmente l'URL potrebbe non aspettarsi che una stringa sia sensibile al maiuscolo/minuscolo. Principio di Least Surprise e tutti. –
La tendenza generale è rimuovere i dettagli della tecnologia dall'URL come '.php'. Oltre a questo le persone escogitano tutti i tipi di strutture URL "semantiche". Non importa molto. – usr