1 00:00:03,650 --> 00:00:06,795 Ora che abbiamo completato 2 00:00:06,795 --> 00:00:11,395 l'implementazione del server API REST utilizzando Express e MongoDB in questo corso, 3 00:00:11,395 --> 00:00:14,990 il prossimo pensiero immediato che potrebbe verificarsi nella tua mente è, 4 00:00:14,990 --> 00:00:20,490 dal momento che abbiamo già sviluppato le applicazioni client nei corsi precedenti, 5 00:00:20,490 --> 00:00:24,930 come possiamo integrare i due insieme in modo che il nostro è in grado di 6 00:00:24,930 --> 00:00:30,880 interagire con il server API REST completo che abbiamo sviluppato in questo corso? 7 00:00:30,880 --> 00:00:33,820 Quindi, questo è ciò che esamineremo in 8 00:00:33,820 --> 00:00:39,820 questa lezione e i due esercizi che seguono questa lezione. 9 00:00:39,820 --> 00:00:41,770 Quindi, alla fine di questa lezione, 10 00:00:41,770 --> 00:00:44,390 avrai React Client che sarà 11 00:00:44,390 --> 00:00:47,330 in grado di comunicare con il server che hai appena sviluppato in 12 00:00:47,330 --> 00:00:50,345 questo corso ed essere in grado di supportare 13 00:00:50,345 --> 00:00:56,510 la vista lato client completa della nostra intera applicazione. 14 00:00:56,510 --> 00:00:58,970 In questo modo vedremo che abbiamo sviluppato 15 00:00:58,970 --> 00:01:02,565 l' 16 00:01:02,565 --> 00:01:07,795 applicazione completa end-to-end dal lato client fino al lato server in questo corso. 17 00:01:07,795 --> 00:01:10,910 Per integrare il client e il server, 18 00:01:10,910 --> 00:01:13,670 come abbiamo capito che il nostro server è già 19 00:01:13,670 --> 00:01:17,525 implementato per supportare l'API REST a tutti gli effetti. 20 00:01:17,525 --> 00:01:19,220 Dal lato client, 21 00:01:19,220 --> 00:01:20,720 che si tratti del client angolare, 22 00:01:20,720 --> 00:01:23,340 del client ionico o del client script nativo, 23 00:01:23,340 --> 00:01:28,240 tutti interagiscono con il server utilizzando gli endpoint API REST. 24 00:01:28,240 --> 00:01:33,630 Pertanto, quando il client invia la richiesta al server presso l'endpoint API REST, 25 00:01:33,630 --> 00:01:38,190 il server risponderà con i dati JSON corrispondenti al client. 26 00:01:38,190 --> 00:01:44,225 Il client può quindi utilizzare i dati JSON per rendere le viste per l'utente. 27 00:01:44,225 --> 00:01:50,450 Quindi, data questa comprensione della comunicazione tra il client e il server, 28 00:01:50,450 --> 00:01:53,745 l'integrazione dovrebbe essere abbastanza semplice. 29 00:01:53,745 --> 00:01:58,475 Ora che abbiamo l'autenticazione utente integrata nel nostro lato server, 30 00:01:58,475 --> 00:02:03,330 abbiamo bisogno di retrofit le nostre applicazioni client per 31 00:02:03,330 --> 00:02:08,400 consentire loro di eseguire l'autenticazione utente sul lato server 32 00:02:08,400 --> 00:02:12,200 postando le informazioni di accesso al server e quindi 33 00:02:12,200 --> 00:02:16,010 ottenendo il token di autenticazione dal 34 00:02:16,010 --> 00:02:19,120 lato server e successivamente comunicare con il server 35 00:02:19,120 --> 00:02:23,700 incluso il token di autenticazione nell'intestazione dei messaggi di richiesta. 36 00:02:23,700 --> 00:02:27,050 Quindi, tutto questo significa che dobbiamo fare piccole regolazioni sia 37 00:02:27,050 --> 00:02:31,345 al client che al server in modo che i due possano comunicare tra loro. 38 00:02:31,345 --> 00:02:36,530 Un aspetto che non ho affrontato nell'esercizio precedente 39 00:02:36,530 --> 00:02:41,970 è il modo in cui il server gestirà i parametri di query che arrivano dal lato client. 40 00:02:41,970 --> 00:02:43,480 Così, come ci siamo resi conto, 41 00:02:43,480 --> 00:02:47,450 quando il lato client invia una richiesta per 42 00:02:47,450 --> 00:02:53,035 un piatto in primo piano o un leader in primo piano o una promozione in primo piano, 43 00:02:53,035 --> 00:02:55,910 abbiamo visto che l'URL include, 44 00:02:55,910 --> 00:02:59,590 piatti caratteristica punto interrogativo è uguale a 45 00:02:59,590 --> 00:03:04,370 true nell'URL della richiesta che proviene dal lato client. 46 00:03:04,370 --> 00:03:07,210 Ora, nei dati sul lato server, 47 00:03:07,210 --> 00:03:09,585 abbiamo già visto che il piatto, la 48 00:03:09,585 --> 00:03:15,370 promozione o il leader includono il flag in primo piano già nei dati JSON. 49 00:03:15,370 --> 00:03:18,649 Quindi, quando questa richiesta arriva sul lato server, 50 00:03:18,649 --> 00:03:21,394 il server dovrebbe essere in grado di estrarre 51 00:03:21,394 --> 00:03:26,765 questo parametro di query dalla richiesta in entrata e quindi 52 00:03:26,765 --> 00:03:32,390 eseguire in modo appropriato la query di 53 00:03:32,390 --> 00:03:39,950 MongoDB e quindi ottenere solo i risultati in cui questo flag in primo piano è impostato su true. 54 00:03:39,950 --> 00:03:41,740 Quindi, per farlo come abbiamo visto, 55 00:03:41,740 --> 00:03:47,075 l'URL che viene utilizzato per inviare la richiesta al server è, 56 00:03:47,075 --> 00:03:52,030 barra piatti punto interrogativo caratterizzato è uguale a true. 57 00:03:52,030 --> 00:03:57,905 Quindi, questo è il modo in cui forniremo i parametri di query al nostro lato server. 58 00:03:57,905 --> 00:04:02,610 Ora in aggiunta, quando queste informazioni vengono ricevute sul lato server, 59 00:04:02,610 --> 00:04:07,430 ora abbiamo visto che in precedenza, quando abbiamo fatto la richiesta get sul lato server, 60 00:04:07,430 --> 00:04:10,190 abbiamo semplicemente detto piatti trovare e poi avremmo trovato 61 00:04:10,190 --> 00:04:13,135 tutti i piatti e poi restituirli quando 62 00:04:13,135 --> 00:04:19,745 la richiesta get viene inviata alla barra percorso piatto router . 63 00:04:19,745 --> 00:04:25,185 La stessa logica si applica sia al router promozionale che al router leader. 64 00:04:25,185 --> 00:04:30,339 Ora, quando includi un parametro di query come quello nell'URL, 65 00:04:30,339 --> 00:04:34,695 come sarà il nostro lato server in grado di estrarre questo parametro di query? 66 00:04:34,695 --> 00:04:35,980 Quindi, questo è dove, 67 00:04:35,980 --> 00:04:42,590 quando la richiesta in arrivo ha questo parametro di query collegato all'URL in arrivo, 68 00:04:42,590 --> 00:04:47,375 il server express elaborerà automaticamente e lo trasformerà in 69 00:04:47,375 --> 00:04:54,445 un oggetto JSON caricato su un messaggio di richiesta che entra sul lato server. 70 00:04:54,445 --> 00:05:00,710 Ora, questo è disponibile sul lato server sotto forma di req.query. 71 00:05:00,710 --> 00:05:06,545 Quindi, qualunque parametro di query includa nell'URL verrà trasformato in 72 00:05:06,545 --> 00:05:11,480 oggetti JSON corrispondenti con le informazioni impostate come 73 00:05:11,480 --> 00:05:16,880 mostrato qui e quindi caricato sull'oggetto richiesta sul lato server. 74 00:05:16,880 --> 00:05:19,940 Quindi, utilizzando req.query sul lato server, 75 00:05:19,940 --> 00:05:23,625 saremo in grado di ottenere questi parametri di query. 76 00:05:23,625 --> 00:05:27,935 Quindi, quando si esegue una richiesta get sul lato server si dice 77 00:05:27,935 --> 00:05:34,115 dishes.find e quindi si include il req.query nella ricerca lì. 78 00:05:34,115 --> 00:05:38,960 Quindi, quando viene 79 00:05:38,960 --> 00:05:44,120 interrogato MongoDB, solo quei record o solo quei documenti per i 80 00:05:44,120 --> 00:05:50,390 quali la funzionalità è impostata su true verranno estratti da MongoDB e forniti di nuovo a 81 00:05:50,390 --> 00:05:57,020 noi all'interno di questo metodo get qui e quindi possono essere restituiti al lato client. 82 00:05:57,020 --> 00:06:05,270 Quindi, questo è semplice come quello nella gestione dei parametri di query sul nostro lato server. 83 00:06:05,270 --> 00:06:10,645 Quindi, questo aggiornamento faremo sia al router piatto, 84 00:06:10,645 --> 00:06:16,880 al router promo e al router leader sul nostro lato server. 85 00:06:16,880 --> 00:06:18,430 La parte successiva è, 86 00:06:18,430 --> 00:06:20,545 ovviamente, Autenticazione utente. 87 00:06:20,545 --> 00:06:22,060 Quindi, come abbiamo capito, 88 00:06:22,060 --> 00:06:24,150 sul lato server abbiamo già 89 00:06:24,150 --> 00:06:29,450 questi endpoint API REST che sono utili per l'autenticazione utente, 90 00:06:29,450 --> 00:06:33,260 in particolare quando fai un post per slash utenti 91 00:06:33,260 --> 00:06:37,100 slash login con il nome utente e la password, 92 00:06:37,100 --> 00:06:41,675 allora sarai in grado di autenticare l'utente sul server lato. 93 00:06:41,675 --> 00:06:46,080 Ora, quando l'utente viene autenticato sul lato server correttamente, 94 00:06:46,080 --> 00:06:50,584 il messaggio di risposta proveniente dal lato server includerà 95 00:06:50,584 --> 00:06:58,880 il token Web JSON nel corpo della risposta del messaggio di risposta in arrivo dal lato server. 96 00:06:58,880 --> 00:07:00,350 Quindi, dal lato client, 97 00:07:00,350 --> 00:07:04,700 dovremmo essere in grado di estrarre questo token e quindi utilizzare questo token successivamente. 98 00:07:04,700 --> 00:07:08,210 Pertanto, quando il client riceve il messaggio di risposta dal 99 00:07:08,210 --> 00:07:12,560 lato server e l'utente viene autenticato correttamente sul lato server, 100 00:07:12,560 --> 00:07:15,220 il messaggio di risposta conterrà il token Web JSON, 101 00:07:15,220 --> 00:07:16,950 che deve essere estratto, 102 00:07:16,950 --> 00:07:20,780 e successivamente il client dovrebbe includere questo token Web JSON 103 00:07:20,780 --> 00:07:26,200 nel intestazione di autorizzazione per ogni richiesta in uscita dal lato client. 104 00:07:26,200 --> 00:07:31,205 Ciò si ottiene salvando il token Web JSON nella memoria locale. 105 00:07:31,205 --> 00:07:35,155 Successivamente, per ogni richiesta di recupero che emettiamo, 106 00:07:35,155 --> 00:07:40,365 possiamo impostare l'intestazione di autorizzazione per contenere il token Web JSON. 107 00:07:40,365 --> 00:07:43,815 Ora, il processo di logout è abbastanza semplice, 108 00:07:43,815 --> 00:07:47,865 se distruggiamo il token Web JSON che abbiamo sul lato client, 109 00:07:47,865 --> 00:07:51,210 allora il client non sarà più in grado di accedere al server. 110 00:07:51,210 --> 00:07:53,930 Quindi, è semplice come distruggere 111 00:07:53,930 --> 00:07:58,180 il token Web JSON sul lato client per disconnettere quel client. 112 00:07:58,180 --> 00:08:00,530 Quindi, data questa comprensione, 113 00:08:00,530 --> 00:08:04,175 vediamo i passaggi che sono coinvolti nel 114 00:08:04,175 --> 00:08:09,840 fare l'autenticazione utente sulla gestione dell'autenticazione utente sul lato client. 115 00:08:09,840 --> 00:08:13,085 Quindi, per gestire l'autenticazione utente sul lato client, 116 00:08:13,085 --> 00:08:19,000 il client invierà una richiesta di post all'endpoint di accesso barra degli utenti 117 00:08:19,000 --> 00:08:24,190 e il corpo della richiesta di post conterrà il nome utente e la password. 118 00:08:24,190 --> 00:08:26,720 Stiamo usando l'autenticazione di login in questo caso. 119 00:08:26,720 --> 00:08:28,695 Ora, per l'autenticazione di Facebook, ancora una volta, 120 00:08:28,695 --> 00:08:32,425 questa è una configurazione diversa di cui non ho intenzione di discutere in questo momento. 121 00:08:32,425 --> 00:08:35,570 Ma il corpo della richiesta come vedi per 122 00:08:35,570 --> 00:08:38,780 l'autenticazione locale conterrà il nome utente e la password. 123 00:08:38,780 --> 00:08:43,220 Pertanto, quando l'utente viene autenticato correttamente sul lato server, 124 00:08:43,220 --> 00:08:46,460 il server risponderà al 125 00:08:46,460 --> 00:08:51,490 client includendo il token Web JSON nel messaggio di risposta. 126 00:08:51,490 --> 00:08:56,150 Pertanto, quando il client riceve il messaggio di risposta dal lato server, 127 00:08:56,150 --> 00:09:00,320 il client dovrà acquisire questo token Web JSON e quindi 128 00:09:00,320 --> 00:09:05,080 salvare il token Web JSON nella memoria locale sul lato client. 129 00:09:05,080 --> 00:09:11,300 Successivamente, il client dovrebbe includere questo token in ogni richiesta in uscita. 130 00:09:11,300 --> 00:09:14,495 Quindi, come si ottiene questo dal lato client? 131 00:09:14,495 --> 00:09:20,285 Prima di tutto, abbiamo bisogno di salvare il token Web JSON nella memoria locale. 132 00:09:20,285 --> 00:09:25,670 Ora, questo si ottiene all'interno del creatore di azioni che gestisce il processo di accesso dell'utente. 133 00:09:25,670 --> 00:09:32,685 Quindi, quando il post viene fatto sul server dal creatore di induzione lato client, 134 00:09:32,685 --> 00:09:36,020 il messaggio di risposta conterrà il token 135 00:09:36,020 --> 00:09:41,540 e questo token viene salvato nel creatore dell'azione che gestisce il processo di accesso dell'utente. 136 00:09:41,540 --> 00:09:45,875 Ora in seguito, quando qualsiasi richiesta di recupero è fatto, 137 00:09:45,875 --> 00:09:52,829 allora possiamo facilmente impostare l'intestazione di autorizzazione nella richiesta di recupero in uscita. 138 00:09:52,829 --> 00:09:56,005 Ora, una volta che il client si disconnette, 139 00:09:56,005 --> 00:09:59,930 il token Web JSON verrà distrutto sul lato client. 140 00:09:59,930 --> 00:10:03,050 Quindi in seguito, le richieste in uscita non conterranno 141 00:10:03,050 --> 00:10:07,490 più il token Web JSON perché il token Web JSON non esiste sul lato client. 142 00:10:07,490 --> 00:10:10,790 Quindi, l'utente perde l'autenticazione. 143 00:10:10,790 --> 00:10:17,455 Quindi, questo è il modo in cui gestiremo il login e il processo di logout sul lato client. 144 00:10:17,455 --> 00:10:21,890 Comunicando con il server e quindi ottenere il token Web JSON e 145 00:10:21,890 --> 00:10:26,185 quindi includendo il token Web JSON in ogni richiesta in uscita. 146 00:10:26,185 --> 00:10:31,570 Ora, con questa comprensione di come il client e il server interagiranno, 147 00:10:31,570 --> 00:10:35,540 passiamo ora ai prossimi due esercizi. 148 00:10:35,540 --> 00:10:40,410 Innanzitutto, aggiorneremo il lato server con alcune aggiunte in modo 149 00:10:40,410 --> 00:10:45,550 che possa integrarsi bene con il nostro lato client. 150 00:10:45,550 --> 00:10:50,075 Successivamente, aggiorneremo il lato client o meglio ti darò 151 00:10:50,075 --> 00:10:54,200 un'applicazione client a tutti gli effetti che ho preso 152 00:10:54,200 --> 00:10:58,875 dalla forza di reazione precedente e l'adattata, aggiornata. 153 00:10:58,875 --> 00:11:03,080 Quindi, ci occuperemo di entrambi nei prossimi due esercizi, 154 00:11:03,080 --> 00:11:09,460 e alla fine di esso capirai come integrare il tuo lato client e server.