Eranius ha scritto:
Il problema però si pone quando devo caricare oltre che ai dati della prenotazione anche l'elenco delle opzioni.
Questo implica un ulteriore richiesta $.ajax post asincrona per caricare l'elenco degli operatori nel select
Stessa cosa avviene per la tipologia in quanto l'id_tipologia è chiave e l'utente vede la descrizione.
In questi casi come ci si comporta?
Innanzitutto: cosa c'entra con Java dato che hai postato in questa sezione? Direi nulla ..
Comunque sì, ho capito cosa intendi. È molto tipico che il front-end debba ricevere anche "altri" dati (oltre alla/e informazioni principali), ad esempio per popolare delle combo-box, liste o per avere delle lookup-table per decodificare codici in descrizioni da mostrare.
Le soluzioni sono due: o si impacchetta tutto quanto in una unica response ... o si fanno request separate per ottenere le singole cose. Ci sono vantaggi/svantaggi per ciascuno dei modi.
Con una unica response, fai ovviamente meno request ma comporta che il server deve comporre un JSON (o altro) con più dati. Se il back-end fosse in Java, si dovrebbero fare
bean specifici per ciascuna response (che comunque è già generalmente così).
Se fai request separate, puoi avere endpoint specifici per ciascuna lista di informazioni, quindi molto più "verticalizzato". In questo caso il front-end potrebbe anche applicare meccanismi di caching.
Mi è capitato di lavorare su una applicazione (io ero sul back-end, non sul front-end) in cui il front-end faceva tante richieste singole per ottenere ciascuna delle lookup-table da usare per combobox o altro. Però applicava dei meccanismi di caching e si "teneva" queste informazioni per un certo tot di tempo. Se anche cambiavi pagina e poi ritornavi sulla precedente, non ri-faceva subito le request per le lut. In questi scenari è solo questione di quanto si vuole rendere "furbo" il front-end.