Ora che abbiamo completato
l'implementazione del server API REST utilizzando Express e MongoDB in questo corso,
il prossimo pensiero immediato che potrebbe verificarsi nella tua mente è,
dal momento che abbiamo già sviluppato le applicazioni client nei corsi precedenti,
come possiamo integrare i due insieme in modo che il nostro è in grado di
interagire con il server API REST completo che abbiamo sviluppato in questo corso?
Quindi, questo è ciò che esamineremo in
questa lezione e i due esercizi che seguono questa lezione.
Quindi, alla fine di questa lezione,
avrai React Client che sarà
in grado di comunicare con il server che hai appena sviluppato in
questo corso ed essere in grado di supportare
la vista lato client completa della nostra intera applicazione.
In questo modo vedremo che abbiamo sviluppato
l'
applicazione completa end-to-end dal lato client fino al lato server in questo corso.
Per integrare il client e il server,
come abbiamo capito che il nostro server è già
implementato per supportare l'API REST a tutti gli effetti.
Dal lato client,
che si tratti del client angolare,
del client ionico o del client script nativo,
tutti interagiscono con il server utilizzando gli endpoint API REST.
Pertanto, quando il client invia la richiesta al server presso l'endpoint API REST,
il server risponderà con i dati JSON corrispondenti al client.
Il client può quindi utilizzare i dati JSON per rendere le viste per l'utente.
Quindi, data questa comprensione della comunicazione tra il client e il server,
l'integrazione dovrebbe essere abbastanza semplice.
Ora che abbiamo l'autenticazione utente integrata nel nostro lato server,
abbiamo bisogno di retrofit le nostre applicazioni client per
consentire loro di eseguire l'autenticazione utente sul lato server
postando le informazioni di accesso al server e quindi
ottenendo il token di autenticazione dal
lato server e successivamente comunicare con il server
incluso il token di autenticazione nell'intestazione dei messaggi di richiesta.
Quindi, tutto questo significa che dobbiamo fare piccole regolazioni sia
al client che al server in modo che i due possano comunicare tra loro.
Un aspetto che non ho affrontato nell'esercizio precedente
è il modo in cui il server gestirà i parametri di query che arrivano dal lato client.
Così, come ci siamo resi conto,
quando il lato client invia una richiesta per
un piatto in primo piano o un leader in primo piano o una promozione in primo piano,
abbiamo visto che l'URL include,
piatti caratteristica punto interrogativo è uguale a
true nell'URL della richiesta che proviene dal lato client.
Ora, nei dati sul lato server,
abbiamo già visto che il piatto, la
promozione o il leader includono il flag in primo piano già nei dati JSON.
Quindi, quando questa richiesta arriva sul lato server,
il server dovrebbe essere in grado di estrarre
questo parametro di query dalla richiesta in entrata e quindi
eseguire in modo appropriato la query di
MongoDB e quindi ottenere solo i risultati in cui questo flag in primo piano è impostato su true.
Quindi, per farlo come abbiamo visto,
l'URL che viene utilizzato per inviare la richiesta al server è,
barra piatti punto interrogativo caratterizzato è uguale a true.
Quindi, questo è il modo in cui forniremo i parametri di query al nostro lato server.
Ora in aggiunta, quando queste informazioni vengono ricevute sul lato server,
ora abbiamo visto che in precedenza, quando abbiamo fatto la richiesta get sul lato server,
abbiamo semplicemente detto piatti trovare e poi avremmo trovato
tutti i piatti e poi restituirli quando
la richiesta get viene inviata alla barra percorso piatto router .
La stessa logica si applica sia al router promozionale che al router leader.
Ora, quando includi un parametro di query come quello nell'URL,
come sarà il nostro lato server in grado di estrarre questo parametro di query?
Quindi, questo è dove,
quando la richiesta in arrivo ha questo parametro di query collegato all'URL in arrivo,
il server express elaborerà automaticamente e lo trasformerà in
un oggetto JSON caricato su un messaggio di richiesta che entra sul lato server.
Ora, questo è disponibile sul lato server sotto forma di req.query.
Quindi, qualunque parametro di query includa nell'URL verrà trasformato in
oggetti JSON corrispondenti con le informazioni impostate come
mostrato qui e quindi caricato sull'oggetto richiesta sul lato server.
Quindi, utilizzando req.query sul lato server,
saremo in grado di ottenere questi parametri di query.
Quindi, quando si esegue una richiesta get sul lato server si dice
dishes.find e quindi si include il req.query nella ricerca lì.
Quindi, quando viene
interrogato MongoDB, solo quei record o solo quei documenti per i
quali la funzionalità è impostata su true verranno estratti da MongoDB e forniti di nuovo a
noi all'interno di questo metodo get qui e quindi possono essere restituiti al lato client.
Quindi, questo è semplice come quello nella gestione dei parametri di query sul nostro lato server.
Quindi, questo aggiornamento faremo sia al router piatto,
al router promo e al router leader sul nostro lato server.
La parte successiva è,
ovviamente, Autenticazione utente.
Quindi, come abbiamo capito,
sul lato server abbiamo già
questi endpoint API REST che sono utili per l'autenticazione utente,
in particolare quando fai un post per slash utenti
slash login con il nome utente e la password,
allora sarai in grado di autenticare l'utente sul server lato.
Ora, quando l'utente viene autenticato sul lato server correttamente,
il messaggio di risposta proveniente dal lato server includerà
il token Web JSON nel corpo della risposta del messaggio di risposta in arrivo dal lato server.
Quindi, dal lato client,
dovremmo essere in grado di estrarre questo token e quindi utilizzare questo token successivamente.
Pertanto, quando il client riceve il messaggio di risposta dal
lato server e l'utente viene autenticato correttamente sul lato server,
il messaggio di risposta conterrà il token Web JSON,
che deve essere estratto,
e successivamente il client dovrebbe includere questo token Web JSON
nel intestazione di autorizzazione per ogni richiesta in uscita dal lato client.
Ciò si ottiene salvando il token Web JSON nella memoria locale.
Successivamente, per ogni richiesta di recupero che emettiamo,
possiamo impostare l'intestazione di autorizzazione per contenere il token Web JSON.
Ora, il processo di logout è abbastanza semplice,
se distruggiamo il token Web JSON che abbiamo sul lato client,
allora il client non sarà più in grado di accedere al server.
Quindi, è semplice come distruggere
il token Web JSON sul lato client per disconnettere quel client.
Quindi, data questa comprensione,
vediamo i passaggi che sono coinvolti nel
fare l'autenticazione utente sulla gestione dell'autenticazione utente sul lato client.
Quindi, per gestire l'autenticazione utente sul lato client,
il client invierà una richiesta di post all'endpoint di accesso barra degli utenti
e il corpo della richiesta di post conterrà il nome utente e la password.
Stiamo usando l'autenticazione di login in questo caso.
Ora, per l'autenticazione di Facebook, ancora una volta,
questa è una configurazione diversa di cui non ho intenzione di discutere in questo momento.
Ma il corpo della richiesta come vedi per
l'autenticazione locale conterrà il nome utente e la password.
Pertanto, quando l'utente viene autenticato correttamente sul lato server,
il server risponderà al
client includendo il token Web JSON nel messaggio di risposta.
Pertanto, quando il client riceve il messaggio di risposta dal lato server,
il client dovrà acquisire questo token Web JSON e quindi
salvare il token Web JSON nella memoria locale sul lato client.
Successivamente, il client dovrebbe includere questo token in ogni richiesta in uscita.
Quindi, come si ottiene questo dal lato client?
Prima di tutto, abbiamo bisogno di salvare il token Web JSON nella memoria locale.
Ora, questo si ottiene all'interno del creatore di azioni che gestisce il processo di accesso dell'utente.
Quindi, quando il post viene fatto sul server dal creatore di induzione lato client,
il messaggio di risposta conterrà il token
e questo token viene salvato nel creatore dell'azione che gestisce il processo di accesso dell'utente.
Ora in seguito, quando qualsiasi richiesta di recupero è fatto,
allora possiamo facilmente impostare l'intestazione di autorizzazione nella richiesta di recupero in uscita.
Ora, una volta che il client si disconnette,
il token Web JSON verrà distrutto sul lato client.
Quindi in seguito, le richieste in uscita non conterranno
più il token Web JSON perché il token Web JSON non esiste sul lato client.
Quindi, l'utente perde l'autenticazione.
Quindi, questo è il modo in cui gestiremo il login e il processo di logout sul lato client.
Comunicando con il server e quindi ottenere il token Web JSON e
quindi includendo il token Web JSON in ogni richiesta in uscita.
Ora, con questa comprensione di come il client e il server interagiranno,
passiamo ora ai prossimi due esercizi.
Innanzitutto, aggiorneremo il lato server con alcune aggiunte in modo
che possa integrarsi bene con il nostro lato client.
Successivamente, aggiorneremo il lato client o meglio ti darò
un'applicazione client a tutti gli effetti che ho preso
dalla forza di reazione precedente e l'adattata, aggiornata.
Quindi, ci occuperemo di entrambi nei prossimi due esercizi,
e alla fine di esso capirai come integrare il tuo lato client e server.