Buona pratica per passare queste informazioni attraverso il parametro URL

Question

Buona pratica per passare queste informazioni attraverso il parametro URL

#1 da (2 voti)

0

Fondamentalmente, supponiamo che un'applicazione gestisca alcune riunioni dell'utente.
Ho una zona filtrante su una pagina che mira a specificare la categoria di elementi che ho bisogno di restituire in modo specifico.

Supponendo due tipi di filtri:

Recupero dei miei incontri effettivi (riunioni che si verificano attualmente o pianificate nel prossimo futuro)
Recupero delle mie riunioni precedenti (riunioni già passate)

Penso di passare un tipo di parametro url come questo:

www.myapp.com?me=actual
o
www.app.com?me=past

In effetti, non posso avere actual e past nella stessa chiamata poiché non sarebbe appropriato per la quotazione.

Quindi nel mio lato server, gestirò attraverso un semplice condizionale il valore passato per filtrare la query.

È giusto passare un string come questo ( past o actual ) o esiste una pratica migliore per gestire questo caso?

Nota che per impostazione predefinita, ovvero senza filtro, vengono restituite tutte le riunioni.

architecture web-applications parameters url

posta Mik378 28.08.2014 - 12:48

fonte

1 risposta

Leggi altre domande sui tag architecture web-applications parameters url

Licenze per librerie esterne Applicazione server client desktop, limitando il campo di area di testo a compromessi con i clienti

score 2 · Accepted Answer

Totalmente standard. Anche se entrambe le opzioni potrebbero essere utilizzate in parallelo, potresti usare qualcosa come me = actual, passato e split sul server. Penso che l'URL dovrebbe leggere qualcosa come www.myapp.com/meetings?me=actual (nel caso in cui tu avresti più funzionalità rispetto alle riunioni e forse vorresti fare il routing RESTful subito o dopo)

Con il modo in cui funzionano gli URL l'altra opzione sarebbe avere qualcosa come www.myapp.com/actual_meetings e www.myapp.com/past_meetings che diventerebbe brutto piuttosto presto e almeno per framework come Rails che usano RESTful route avrebbero bisogno di qualche lavoro extra dove non necessario. Anche questo non ha molta flessibilità nel caso in cui sia necessario aggiungere più opzioni, non menzionare anche altri casi in cui le opzioni sono generate dinamicamente dalle voci del database.

Certe cose possono dipendere dalla tecnologia di base, ovviamente, ma per la maggior parte dei siti web vedrai parametri usati per dettagli così piccoli in cui un'azione di un controller può gestire richieste molto simili (dove la differenza è principalmente un dettaglio nella query SQL e

la logica di business e il rendering di visualizzazione di html rimangono uguali)

Da una prospettiva REST ciò sarebbe piuttosto ovvio, poiché le riunioni sono chiaramente una risorsa REST e quello che fai chiamerebbe solo l'azione indice (quindi www.myapp.com/meetings in plurale) e quali incontri mostrare solo una questione di quei parametri.