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 vostra mente è,
dal momento che abbiamo già sviluppato le applicazioni client,
sia che si tratti dell'applicazione angolare, dell'applicazione ionica,
o del Applicazione Native Script nei corsi precedenti,
come possiamo integrare i due insieme in modo che la nostra applicazione client sia in grado di
interagire con il server API REST completo che abbiamo sviluppato in questo corso?
Quindi, questo è ciò che esamineremo in questa lezione,
in questa lezione, e i due esercizi che seguono questa lezione.
Quindi, alla fine di questa lezione,
avrai un client Angular che saremo
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.
Quindi, in questo modo, vedremo che abbiamo sviluppato
l'applicazione end-to-end completa dal lato client fino al lato server.
Un approccio simile può essere utilizzato anche con
il client Ionic o con il client di script Native,
dato che sia lo script ionico che nativo sono stati
sviluppati con il motore angolare dietro le quinte.
Quindi, eseguire un insieme simile di passaggi dovrebbe essere in grado di rendere il vostro client Ionic e anche
il vostro client script Native comunicare con il
server API di riposo Express più MongoDB che abbiamo sviluppato in questo corso.
Per integrare il client e il server,
come abbiamo capito, 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
e il client può quindi utilizzare i dati JSON per eseguire il rendering delle viste per l'utente.
Quindi, data questa comprensione della comunicazione tra il client e il server,
l'integrazione dovrebbe essere abbastanza semplice.
Ma, ora, naturalmente,
quando abbiamo sviluppato il nostro client Angular o Ionic o NativeScript,
non abbiamo fatto la parte di autenticazione utente completa,
perché non l'avevamo nel nostro server JSON.
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, comunicando 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 di funzionalità,
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,
include il flag della funzione 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,
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 è/dish? feature=true.
Quindi, questo è il modo in cui forniremo i parametri di query al nostro lato server.
Ora, inoltre, 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 al dishRouterRoute/.
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, indipendentemente dai parametri di query che includi 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, 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 è, naturalmente, l'autenticazione dell'utente.
Quindi, come abbiamo capito sul lato server,
abbiamo già questi endpoint API REST,
che sono utili per l'autenticazione dell'utente.
In particolare, quando fai un post su/users/login,
con il nome utente e la password, allora,
sarai in grado di autenticare l'utente sul lato server.
Ora, quando l'utente viene autenticato correttamente sul lato server,
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 per ogni richiesta in uscita dal lato client.
Quindi, come gestiamo l'intera serie di operazioni?
Ora, questo è dove implementeremo
un altro servizio che verrà utilizzato sul nostro lato client,
nel nostro client angolare,
chiamato il servizio di autenticazione,
ed è lì che gestiremo l'intero login e le operazioni di logout.
Ora, il processo di logout è abbastanza semplice ma,
se distruggiamo il token web JSON che abbiamo sul lato client,
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 e gestire l'autenticazione utente sul lato client.
Quindi, per gestire l'autenticazione utente sul lato client,
il client invierà una richiesta di post all'endpoint /users/login
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 di nuovo,
questa è una configurazione diversa di cui non ho intenzione di discutere in questo momento.
Ma, il corpo della richiesta, come vedrai 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?
Innanzitutto, ovviamente,
è necessario salvare il token Web JSON in ingresso nell'archiviazione locale
e ciò avviene nel servizio di autenticazione che implementeremo sul lato client.
Ora, per ogni richiesta in uscita,
il client includerà questo token nell'intestazione,
l'intestazione di autorizzazione della richiesta in uscita.
Ora, come si realizza questo?
Quindi, questo è dove stiamo andando a prendere l'aiuto di un intercettore HTTP,
che il HttpClient in Angular supporta.
Quindi, con l'intercettore HTTP,
l'intercettore ci permette di intercettare
ogni messaggio di richiesta in uscita o anche
intercettare ogni messaggio di risposta in arrivo se lo si sceglie.
Ma nell'applicazione Angular,
implementeremo l'intercettore di richiesta,
che illustrerò nell'esercizio più avanti.
Nell' intercettore di richiesta HTTP,
quando il messaggio di richiesta viene intercettato,
ogni messaggio di richiesta in uscita verrà intercettato e quindi il token Web JSON
verrà inserito nell'intestazione di autorizzazione del messaggio di richiesta.
Successivamente, il messaggio di richiesta verrebbe trasmesso sul lato server.
Quindi, ogni richiesta in uscita dopo che l'utente è stato autenticato sul lato server,
ogni richiesta in uscita dal lato client porterà
il token web JSON nell'intestazione di autorizzazione della richiesta 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, in tal modo, l'utente perde l'autenticazione.
Quindi, questo è il modo in cui gestiremo il processo di login e logout sul lato client,
comunicando con il server
e quindi ottenendo 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 sito client.
Successivamente, aggiorneremo il lato client o meglio ti darò
un'applicazione client completa che ho
preso dal precedente corso Angular e quindi lo aggiornerò, il
che ci fornisce anche la possibilità di utilizzare intercettori HTTP
sia sulle richieste in uscita che sul messaggi di risposta in arrivo.
Quindi, ci occuperemo di entrambi nei prossimi due esercizi,
e alla fine di esso, capirai come
integrare il tuo client e il lato server.