Ho una domanda su come strutturare una risposta in cui restituisco oggetti relativi ad altri oggetti (uno-a-molti / molti-a-uno) e a dirmi se il modo in cui ho strutturato i miei endpoint è sbagliato o no, o se c'è un modo migliore.
Il mio scenario: Ho un'app JS costruita su Flux dove ho questi negozi: - Riunioni - Utenti
Per semplicità, diciamo che l'utente finale è un gestore di riunioni e desidera vedere una tabella / elenco di tutte le riunioni e ogni riga visualizzerà la descrizione e la data della riunione, oltre ai nomi, alle e-mail e ai partecipanti telefoni.
Quindi, a caricamento della pagina, faccio una richiesta alla rotta / riunioni che restituisce un oggetto come questo:
{
meetings: [
{id: 1, date: '2016-01-01', attendees: [1, 2, 3]},
{id: 2, date: '2016-01-02', attendees: [2, 3, 4]},
],
allUsersIntersectedByMeetings: [
{1, name: 'a', phone: '1800-01111'},
{2, name: 'b', phone: '1800-02222'},
{3, name: 'c', phone: '1800-03333'},
{4, name: 'd', phone: '1800-04444'},
]
}
Se si nota, ho separato i dati degli utenti dall'array delle riunioni, questo è per compattare il risultato e impedire l'invio di informazioni duplicate sullo stesso utente (nel mio esempio i dati dell'utente sono piuttosto piccoli, ma nella vita reale lì potrebbero essere molte colonne sulla tabella utente).
Il motivo per cui ho disaccoppiato le riunioni e gli utenti, è che non voglio restituire tonnellate di dati duplicati, perché nella vita reale tratterò almeno cento riunioni in una richiesta e gli utenti potrebbero ripetere molte volte attraverso diversi incontri.
Quindi con questa struttura, metto tutti i clienti nel mio flux store front-end 'Users', e manterrò tutti i miei dati in sincronia. Esempio: se volessi modificare il telefono di un utente, lo farò direttamente nell'archivio degli utenti e questo si propagherà attraverso l'interfaccia utente dove altri incontri fanno riferimento allo stesso utente. Non devo assolutamente toccare gli oggetti della riunione.
Inoltre, potrei incorrere in un problema in cui dovrei anche restituire dati nidificati sugli utenti, come le informazioni sulla loro società:
{userId: 1, name: 'a', phone: '1800-0111', email: '[email protected]', companyId: 10}
{companyId: 10, phone: '1900-02222', name: 'ACME INC'}.
Pensi che mi stia preoccupando troppo della larghezza di banda della rete? Dovrei semplicemente restituire le riunioni con i dati degli utenti popolati (ala 'MongoDB)?.
O dovrei semplicemente restituire le riunioni ed eseguire una richiesta separata per recuperare utenti unici sotto endpoint API degli utenti come '/ users? filterById = 1,2,3'? Anche se mi piace questo approccio, sarei preoccupato per la velocità, se per esempio lascio che l'utente finale cerchi le riunioni su una casella di input e su ogni evento di modifica dell'ingresso aggiorni i risultati (come una ricerca elastica). Penso che i risultati si sentirebbero molto lenti a comparire se mi venisse richiesto di mostrare le informazioni dei suoi utenti allo stesso tempo. Pensieri?
Esiste un modo de facto per risolvere questi problemi con REST? Quali sarebbero i tuoi suggerimenti?
Grazie.