1
00:00:00,000 --> 00:00:05,340
Ora che abbiamo

2
00:00:05,340 --> 00:00:11,610
completato l'implementazione del server API REST utilizzando Express e MongoDB in questo corso,

3
00:00:11,610 --> 00:00:14,990
il prossimo pensiero immediato che potrebbe verificarsi nella vostra mente è,

4
00:00:14,990 --> 00:00:18,555
dal momento che abbiamo già sviluppato le applicazioni client,

5
00:00:18,555 --> 00:00:21,460
sia che si tratti dell'applicazione angolare, dell'applicazione ionica,

6
00:00:21,460 --> 00:00:25,380
o del Applicazione Native Script nei corsi precedenti,

7
00:00:25,380 --> 00:00:29,820
come possiamo integrare i due insieme in modo che la nostra applicazione client sia in grado di

8
00:00:29,820 --> 00:00:35,780
interagire con il server API REST completo che abbiamo sviluppato in questo corso?

9
00:00:35,780 --> 00:00:39,605
Quindi, questo è ciò che esamineremo in questa lezione,

10
00:00:39,605 --> 00:00:44,715
in questa lezione, e i due esercizi che seguono questa lezione.

11
00:00:44,715 --> 00:00:46,655
Quindi, alla fine di questa lezione,

12
00:00:46,655 --> 00:00:49,295
avrai un client Angular che saremo

13
00:00:49,295 --> 00:00:52,220
in grado di comunicare con il server che hai appena sviluppato in

14
00:00:52,220 --> 00:00:55,265
questo corso ed essere in grado di supportare

15
00:00:55,265 --> 00:01:01,410
la vista lato client completa della nostra intera applicazione.

16
00:01:01,410 --> 00:01:03,860
Quindi, in questo modo, vedremo che abbiamo sviluppato

17
00:01:03,860 --> 00:01:11,150
l'applicazione end-to-end completa dal lato client fino al lato server.

18
00:01:11,150 --> 00:01:13,895
Un approccio simile può essere utilizzato anche con

19
00:01:13,895 --> 00:01:17,290
il client Ionic o con il client di script Native,

20
00:01:17,290 --> 00:01:20,430
dato che sia lo script ionico che nativo sono stati

21
00:01:20,430 --> 00:01:24,420
sviluppati con il motore angolare dietro le quinte.

22
00:01:24,420 --> 00:01:31,100
Quindi, eseguire un insieme simile di passaggi dovrebbe essere in grado di rendere il vostro client Ionic e anche

23
00:01:31,100 --> 00:01:35,240
il vostro client script Native comunicare con il

24
00:01:35,240 --> 00:01:40,295
server API di riposo Express più MongoDB che abbiamo sviluppato in questo corso.

25
00:01:40,295 --> 00:01:43,415
Per integrare il client e il server,

26
00:01:43,415 --> 00:01:44,810
come abbiamo capito, il

27
00:01:44,810 --> 00:01:50,020
nostro server è già implementato per supportare l'API REST a tutti gli effetti.

28
00:01:50,020 --> 00:01:51,695
Dal lato client,

29
00:01:51,695 --> 00:01:53,240
che si tratti del client angolare,

30
00:01:53,240 --> 00:01:55,750
del client ionico o del client script nativo,

31
00:01:55,750 --> 00:02:00,740
tutti interagiscono con il server utilizzando gli endpoint API REST.

32
00:02:00,740 --> 00:02:06,135
Pertanto, quando il client invia la richiesta al server presso l'endpoint API REST,

33
00:02:06,135 --> 00:02:10,729
il server risponderà con i dati JSON corrispondenti al client

34
00:02:10,729 --> 00:02:16,720
e il client può quindi utilizzare i dati JSON per eseguire il rendering delle viste per l'utente.

35
00:02:16,720 --> 00:02:22,970
Quindi, data questa comprensione della comunicazione tra il client e il server,

36
00:02:22,970 --> 00:02:25,780
l'integrazione dovrebbe essere abbastanza semplice.

37
00:02:25,780 --> 00:02:26,960
Ma, ora, naturalmente,

38
00:02:26,960 --> 00:02:30,820
quando abbiamo sviluppato il nostro client Angular o Ionic o NativeScript,

39
00:02:30,820 --> 00:02:34,990
non abbiamo fatto la parte di autenticazione utente completa,

40
00:02:34,990 --> 00:02:38,225
perché non l'avevamo nel nostro server JSON.

41
00:02:38,225 --> 00:02:43,250
Ora che abbiamo l'autenticazione utente integrata nel nostro lato server,

42
00:02:43,250 --> 00:02:47,810
abbiamo bisogno di retrofit le nostre applicazioni client per

43
00:02:47,810 --> 00:02:52,970
consentire loro di eseguire l'autenticazione utente sul lato server,

44
00:02:52,970 --> 00:02:56,660
postando le informazioni di accesso al server e quindi

45
00:02:56,660 --> 00:03:01,190
ottenendo il token di autenticazione dal lato server,

46
00:03:01,190 --> 00:03:04,400
e successivamente, comunicando con il server incluso

47
00:03:04,400 --> 00:03:08,175
il token di autenticazione nell'intestazione dei messaggi di richiesta.

48
00:03:08,175 --> 00:03:10,130
Quindi, tutto questo significa che dobbiamo fare

49
00:03:10,130 --> 00:03:12,860
piccole regolazioni sia al client che al server,

50
00:03:12,860 --> 00:03:15,860
in modo che i due possano comunicare tra loro.

51
00:03:15,860 --> 00:03:21,020
Un aspetto che non ho affrontato nell'esercizio precedente

52
00:03:21,020 --> 00:03:26,445
è il modo in cui il server gestirà i parametri di query che arrivano dal lato client.

53
00:03:26,445 --> 00:03:27,970
Così, come ci siamo resi conto,

54
00:03:27,970 --> 00:03:31,925
quando il lato client invia una richiesta per

55
00:03:31,925 --> 00:03:37,360
un piatto in primo piano o un leader in primo piano o una promozione di funzionalità,

56
00:03:37,360 --> 00:03:41,665
abbiamo visto che l'URL include piatti,

57
00:03:41,665 --> 00:03:45,095
caratteristica punto interrogativo è uguale a true nell'

58
00:03:45,095 --> 00:03:48,840
URL della richiesta che proviene dal lato client.

59
00:03:48,840 --> 00:03:51,670
Ora, nei dati sul lato server,

60
00:03:51,670 --> 00:03:54,040
abbiamo già visto che il piatto, la

61
00:03:54,040 --> 00:03:56,090
promozione o il leader,

62
00:03:56,090 --> 00:03:59,835
include il flag della funzione già nei dati JSON.

63
00:03:59,835 --> 00:04:02,975
Quindi, quando questa richiesta arriva sul lato server,

64
00:04:02,975 --> 00:04:10,285
il server dovrebbe essere in grado di estrarre questo parametro di query dalla richiesta in entrata,

65
00:04:10,285 --> 00:04:16,865
quindi eseguire in modo appropriato la query di

66
00:04:16,865 --> 00:04:24,485
MongoDB e quindi ottenere solo i risultati in cui questo flag in primo piano è impostato su true.

67
00:04:24,485 --> 00:04:26,365
Quindi, per farlo come abbiamo visto,

68
00:04:26,365 --> 00:04:36,380
l'URL che viene utilizzato per inviare la richiesta al server è/dish? feature=true.

69
00:04:36,380 --> 00:04:42,365
Quindi, questo è il modo in cui forniremo i parametri di query al nostro lato server.

70
00:04:42,365 --> 00:04:47,510
Ora, inoltre, quando queste informazioni vengono ricevute sul lato server,

71
00:04:47,510 --> 00:04:51,890
ora, abbiamo visto che in precedenza, quando abbiamo fatto la richiesta get sul lato server,

72
00:04:51,890 --> 00:04:56,975
abbiamo semplicemente detto piatti trovare e poi avremmo trovato tutti i piatti e poi restituirli

73
00:04:56,975 --> 00:05:03,675
quando la richiesta get viene inviata al dishRouterRoute/.

74
00:05:03,675 --> 00:05:09,470
La stessa logica si applica sia al router promozionale che al router leader.

75
00:05:09,470 --> 00:05:14,805
Ora, quando includi un parametro di query come quello nell'URL,

76
00:05:14,805 --> 00:05:19,270
come sarà il nostro lato server in grado di estrarre questo parametro di query?

77
00:05:19,270 --> 00:05:22,730
Quindi, questo è dove quando la richiesta in arrivo ha

78
00:05:22,730 --> 00:05:27,055
questo parametro di query collegato all'URL in arrivo,

79
00:05:27,055 --> 00:05:31,835
il server express elaborerà automaticamente e lo trasformerà in

80
00:05:31,835 --> 00:05:38,910
un oggetto JSON caricato su un messaggio di richiesta che entra sul lato server.

81
00:05:38,910 --> 00:05:45,185
Ora, questo è disponibile sul lato server sotto forma di req.query.

82
00:05:45,185 --> 00:05:49,665
Quindi, indipendentemente dai parametri di query che includi nell'URL,

83
00:05:49,665 --> 00:05:56,860
verrà trasformato in oggetti JSON corrispondenti con le informazioni impostate come mostrato qui

84
00:05:56,860 --> 00:06:01,350
e quindi caricato sull'oggetto richiesta sul lato server.

85
00:06:01,350 --> 00:06:04,670
Quindi, utilizzando req.query sul lato server,

86
00:06:04,670 --> 00:06:08,105
saremo in grado di ottenere questi parametri di query.

87
00:06:08,105 --> 00:06:11,840
Quindi, quando si esegue una richiesta get sul lato server,

88
00:06:11,840 --> 00:06:18,635
si dice dishes.find e quindi si include il req.query nella ricerca lì.

89
00:06:18,635 --> 00:06:25,040
Quindi, quindi, quando viene interrogato MongoDB,

90
00:06:25,040 --> 00:06:31,160
solo quei record o solo quei documenti per i quali la funzionalità è impostata su true verranno

91
00:06:31,160 --> 00:06:38,270
estratti da MongoDB e forniti di nuovo a noi all'interno di questo metodo get qui,

92
00:06:38,270 --> 00:06:41,625
e quindi, possono essere restituiti al lato client.

93
00:06:41,625 --> 00:06:49,745
Quindi, questo è semplice come quello nella gestione dei parametri di query sul nostro lato server.

94
00:06:49,745 --> 00:06:55,135
Quindi, questo aggiornamento faremo sia al router piatto,

95
00:06:55,135 --> 00:07:01,225
al router promo e al router leader sul nostro lato server.

96
00:07:01,225 --> 00:07:04,880
La parte successiva è, naturalmente, l'autenticazione dell'utente.

97
00:07:04,880 --> 00:07:07,530
Quindi, come abbiamo capito sul lato server,

98
00:07:07,530 --> 00:07:11,095
abbiamo già questi endpoint API REST,

99
00:07:11,095 --> 00:07:13,780
che sono utili per l'autenticazione dell'utente.

100
00:07:13,780 --> 00:07:18,855
In particolare, quando fai un post su/users/login,

101
00:07:18,855 --> 00:07:22,040
con il nome utente e la password, allora,

102
00:07:22,040 --> 00:07:26,140
sarai in grado di autenticare l'utente sul lato server.

103
00:07:26,140 --> 00:07:30,535
Ora, quando l'utente viene autenticato correttamente sul lato server,

104
00:07:30,535 --> 00:07:35,059
il messaggio di risposta proveniente dal lato server includerà

105
00:07:35,059 --> 00:07:43,345
il token Web JSON nel corpo della risposta del messaggio di risposta in arrivo dal lato server.

106
00:07:43,345 --> 00:07:44,810
Quindi, dal lato client,

107
00:07:44,810 --> 00:07:49,210
dovremmo essere in grado di estrarre questo token e quindi utilizzare questo token successivamente.

108
00:07:49,210 --> 00:07:52,700
Pertanto, quando il client riceve il messaggio di risposta dal

109
00:07:52,700 --> 00:07:57,140
lato server e l'utente viene autenticato correttamente sul lato server,

110
00:07:57,140 --> 00:07:59,690
il messaggio di risposta conterrà il token Web JSON,

111
00:07:59,690 --> 00:08:02,290
che deve essere estratto, e successivamente,

112
00:08:02,290 --> 00:08:05,240
il client dovrebbe includere questo token Web JSON

113
00:08:05,240 --> 00:08:10,620
nel per ogni richiesta in uscita dal lato client.

114
00:08:10,620 --> 00:08:13,585
Quindi, come gestiamo l'intera serie di operazioni?

115
00:08:13,585 --> 00:08:15,800
Ora, questo è dove implementeremo

116
00:08:15,800 --> 00:08:20,255
un altro servizio che verrà utilizzato sul nostro lato client,

117
00:08:20,255 --> 00:08:21,720
nel nostro client angolare,

118
00:08:21,720 --> 00:08:23,810
chiamato il servizio di autenticazione,

119
00:08:23,810 --> 00:08:30,185
ed è lì che gestiremo l'intero login e le operazioni di logout.

120
00:08:30,185 --> 00:08:33,850
Ora, il processo di logout è abbastanza semplice ma,

121
00:08:33,850 --> 00:08:37,840
se distruggiamo il token web JSON che abbiamo sul lato client,

122
00:08:37,840 --> 00:08:41,160
il client non sarà più in grado di accedere al server.

123
00:08:41,160 --> 00:08:43,850
Quindi, è semplice come distruggere

124
00:08:43,850 --> 00:08:48,095
il token web JSON sul lato client per disconnettere quel client.

125
00:08:48,095 --> 00:08:50,460
Quindi, data questa comprensione,

126
00:08:50,460 --> 00:08:54,110
vediamo i passaggi che sono coinvolti nel

127
00:08:54,110 --> 00:08:59,760
fare l'autenticazione utente e gestire l'autenticazione utente sul lato client.

128
00:08:59,760 --> 00:09:03,320
Quindi, per gestire l'autenticazione utente sul lato client,

129
00:09:03,320 --> 00:09:08,945
il client invierà una richiesta di post all'endpoint /users/login

130
00:09:08,945 --> 00:09:14,110
e il corpo della richiesta di post conterrà il nome utente e la password.

131
00:09:14,110 --> 00:09:16,660
Stiamo usando l'autenticazione di login in questo caso.

132
00:09:16,660 --> 00:09:18,650
Ora, per l'autenticazione di Facebook di nuovo,

133
00:09:18,650 --> 00:09:22,355
questa è una configurazione diversa di cui non ho intenzione di discutere in questo momento.

134
00:09:22,355 --> 00:09:26,465
Ma, il corpo della richiesta, come vedrai per l'autenticazione locale,

135
00:09:26,465 --> 00:09:28,730
conterrà il nome utente e la password.

136
00:09:28,730 --> 00:09:33,170
Pertanto, quando l'utente viene autenticato correttamente sul lato server,

137
00:09:33,170 --> 00:09:36,410
il server risponderà al

138
00:09:36,410 --> 00:09:41,425
client includendo il token Web JSON nel messaggio di risposta.

139
00:09:41,425 --> 00:09:46,070
Pertanto, quando il client riceve il messaggio di risposta dal lato server,

140
00:09:46,070 --> 00:09:49,790
il client dovrà acquisire questo token Web JSON

141
00:09:49,790 --> 00:09:55,025
e quindi salvare il token Web JSON nella memoria locale sul lato client.

142
00:09:55,025 --> 00:10:01,250
Successivamente, il client dovrebbe includere questo token in ogni richiesta in uscita.

143
00:10:01,250 --> 00:10:04,455
Quindi, come si ottiene questo dal lato client?

144
00:10:04,455 --> 00:10:06,155
Innanzitutto, ovviamente,

145
00:10:06,155 --> 00:10:11,980
è necessario salvare il token Web JSON in ingresso nell'archiviazione locale

146
00:10:11,980 --> 00:10:16,790
e ciò avviene nel servizio di autenticazione che implementeremo sul lato client.

147
00:10:16,790 --> 00:10:19,975
Ora, per ogni richiesta in uscita,

148
00:10:19,975 --> 00:10:22,850
il client includerà questo token nell'intestazione,

149
00:10:22,850 --> 00:10:27,100
l'intestazione di autorizzazione della richiesta in uscita.

150
00:10:27,100 --> 00:10:28,555
Ora, come si realizza questo?

151
00:10:28,555 --> 00:10:33,935
Quindi, questo è dove stiamo andando a prendere l'aiuto di un intercettore HTTP,

152
00:10:33,935 --> 00:10:37,265
che il HttpClient in Angular supporta.

153
00:10:37,265 --> 00:10:39,675
Quindi, con l'intercettore HTTP,

154
00:10:39,675 --> 00:10:42,305
l'intercettore ci permette di intercettare

155
00:10:42,305 --> 00:10:45,875
ogni messaggio di richiesta in uscita o anche

156
00:10:45,875 --> 00:10:50,010
intercettare ogni messaggio di risposta in arrivo se lo si sceglie.

157
00:10:50,010 --> 00:10:52,175
Ma nell'applicazione Angular,

158
00:10:52,175 --> 00:10:56,215
implementeremo l'intercettore di richiesta,

159
00:10:56,215 --> 00:10:59,540
che illustrerò nell'esercizio più avanti.

160
00:10:59,540 --> 00:11:02,460
Nell' intercettore di richiesta HTTP,

161
00:11:02,460 --> 00:11:04,375
quando il messaggio di richiesta viene intercettato,

162
00:11:04,375 --> 00:11:09,915
ogni messaggio di richiesta in uscita verrà intercettato e quindi il token Web JSON

163
00:11:09,915 --> 00:11:15,650
verrà inserito nell'intestazione di autorizzazione del messaggio di richiesta.

164
00:11:15,650 --> 00:11:20,290
Successivamente, il messaggio di richiesta verrebbe trasmesso sul lato server.

165
00:11:20,290 --> 00:11:26,825
Quindi, ogni richiesta in uscita dopo che l'utente è stato autenticato sul lato server,

166
00:11:26,825 --> 00:11:30,620
ogni richiesta in uscita dal lato client porterà

167
00:11:30,620 --> 00:11:35,590
il token web JSON nell'intestazione di autorizzazione della richiesta in uscita.

168
00:11:35,590 --> 00:11:38,600
Ora, una volta che il client si disconnette,

169
00:11:38,600 --> 00:11:42,595
il token Web JSON verrà distrutto sul lato client.

170
00:11:42,595 --> 00:11:47,215
Quindi, in seguito, le richieste in uscita non conterranno più il token Web JSON,

171
00:11:47,215 --> 00:11:50,160
perché il token Web JSON non esiste sul lato client.

172
00:11:50,160 --> 00:11:53,240
Quindi, in tal modo, l'utente perde l'autenticazione.

173
00:11:53,240 --> 00:12:00,030
Quindi, questo è il modo in cui gestiremo il processo di login e logout sul lato client,

174
00:12:00,030 --> 00:12:02,290
comunicando con il server

175
00:12:02,290 --> 00:12:04,225
e quindi ottenendo il token web JSON

176
00:12:04,225 --> 00:12:08,845
e quindi includendo il token web JSON in ogni richiesta in uscita.

177
00:12:08,845 --> 00:12:14,250
Ora, con questa comprensione di come il client e il server interagiranno,

178
00:12:14,250 --> 00:12:18,205
passiamo ora ai prossimi due esercizi.

179
00:12:18,205 --> 00:12:22,540
Innanzitutto, aggiorneremo il lato server con alcune aggiunte, in

180
00:12:22,540 --> 00:12:28,220
modo che possa integrarsi bene con il nostro sito client.

181
00:12:28,220 --> 00:12:32,750
Successivamente, aggiorneremo il lato client o meglio ti darò

182
00:12:32,750 --> 00:12:36,215
un'applicazione client completa che ho

183
00:12:36,215 --> 00:12:40,795
preso dal precedente corso Angular e quindi lo aggiornerò, il

184
00:12:40,795 --> 00:12:45,875
che ci fornisce anche la possibilità di utilizzare intercettori HTTP

185
00:12:45,875 --> 00:12:51,595
sia sulle richieste in uscita che sul messaggi di risposta in arrivo.

186
00:12:51,595 --> 00:12:56,090
Quindi, ci occuperemo di entrambi nei prossimi due esercizi,

187
00:12:56,090 --> 00:12:58,370
e alla fine di esso, capirai come

188
00:12:58,370 --> 00:13:02,530
integrare il tuo client e il lato server.