1
00:00:00,000 --> 00:00:05,340
Agora que

2
00:00:05,340 --> 00:00:11,610
concluímos a implementação do servidor REST API usando Express e MongoDB neste curso,

3
00:00:11,610 --> 00:00:14,990
o próximo pensamento imediato que pode ocorrer em sua mente é,

4
00:00:14,990 --> 00:00:18,555
uma vez que já desenvolvemos os aplicativos cliente,

5
00:00:18,555 --> 00:00:21,460
seja o aplicativo Angular, o aplicativo Ionic,

6
00:00:21,460 --> 00:00:25,380
ou o Aplicativo de Script nativo nos cursos anteriores,

7
00:00:25,380 --> 00:00:29,820
como integramos os dois juntos para que nosso aplicativo cliente seja capaz de

8
00:00:29,820 --> 00:00:35,780
interagir com o servidor API REST completo que desenvolvemos neste curso?

9
00:00:35,780 --> 00:00:39,605
Então, isto é o que vamos examinar nesta lição,

10
00:00:39,605 --> 00:00:44,715
nesta palestra, e os dois exercícios que se seguem a esta palestra.

11
00:00:44,715 --> 00:00:46,655
Então, ao final desta lição,

12
00:00:46,655 --> 00:00:49,295
você terá um cliente Angular que poderemos nos

13
00:00:49,295 --> 00:00:52,220
comunicar com o servidor que você acabou de desenvolver

14
00:00:52,220 --> 00:00:55,265
neste curso e ser capaz de suportar

15
00:00:55,265 --> 00:01:01,410
a visão completa do lado do cliente de toda a nossa aplicação.

16
00:01:01,410 --> 00:01:03,860
Então, dessa forma, vamos ver que temos desenvolvido

17
00:01:03,860 --> 00:01:11,150
o aplicativo completo de ponta a ponta do lado do cliente todo o caminho para o lado do servidor.

18
00:01:11,150 --> 00:01:13,895
Uma abordagem semelhante também pode ser usada com

19
00:01:13,895 --> 00:01:17,290
seu cliente Ionic ou com seu cliente de script nativo,

20
00:01:17,290 --> 00:01:20,430
dado o fato de que ambos os scripts Ionic e Native foram

21
00:01:20,430 --> 00:01:24,420
desenvolvidos com o mecanismo Angular nos bastidores.

22
00:01:24,420 --> 00:01:31,100
Assim, realizar um conjunto semelhante de etapas deve ser capaz de fazer o seu cliente Ionic e também

23
00:01:31,100 --> 00:01:35,240
seu cliente de script nativo se comunicar com o

24
00:01:35,240 --> 00:01:40,295
servidor de API de descanso Express mais MongoDB que desenvolvemos neste curso.

25
00:01:40,295 --> 00:01:43,415
Para integrar o cliente e o servidor,

26
00:01:43,415 --> 00:01:44,810
como percebemos,

27
00:01:44,810 --> 00:01:50,020
nosso servidor já está implementado para suportar a API REST completa.

28
00:01:50,020 --> 00:01:51,695
Do lado do nosso cliente,

29
00:01:51,695 --> 00:01:53,240
seja o cliente angular,

30
00:01:53,240 --> 00:01:55,750
o cliente iônico ou o cliente de script nativo,

31
00:01:55,750 --> 00:02:00,740
todos eles interagem com o servidor usando os endpoints da API REST.

32
00:02:00,740 --> 00:02:06,135
Assim, quando o cliente envia a solicitação para o servidor no ponto final da API REST,

33
00:02:06,135 --> 00:02:10,729
o servidor responderá com os dados JSON correspondentes de volta ao cliente,

34
00:02:10,729 --> 00:02:16,720
e o cliente pode então fazer uso dos dados JSON para renderizar as exibições para o usuário.

35
00:02:16,720 --> 00:02:22,970
Assim, dado este entendimento da comunicação entre o cliente e o servidor,

36
00:02:22,970 --> 00:02:25,780
a integração deve ser bastante simples.

37
00:02:25,780 --> 00:02:26,960
Mas, agora é claro,

38
00:02:26,960 --> 00:02:30,820
quando desenvolvemos nosso cliente Angular ou Ionic ou NativeScript,

39
00:02:30,820 --> 00:02:34,990
não fizemos a parte completa de autenticação do usuário,

40
00:02:34,990 --> 00:02:38,225
porque não tínhamos isso em nosso servidor JSON.

41
00:02:38,225 --> 00:02:43,250
Agora que temos a autenticação do usuário embutida em nosso lado do servidor,

42
00:02:43,250 --> 00:02:47,810
precisamos atualizar nossos aplicativos cliente para

43
00:02:47,810 --> 00:02:52,970
habilitá-los a fazer autenticação do usuário no lado do servidor,

44
00:02:52,970 --> 00:02:56,660
postando as informações de login no servidor e, em seguida,

45
00:02:56,660 --> 00:03:01,190
obtendo o token de autenticação do lado do servidor,

46
00:03:01,190 --> 00:03:04,400
e, posteriormente, comunicando-se com o servidor, incluindo

47
00:03:04,400 --> 00:03:08,175
o token de autenticação no cabeçalho das mensagens de solicitação.

48
00:03:08,175 --> 00:03:10,130
Então, tudo isso significa que precisamos fazer

49
00:03:10,130 --> 00:03:12,860
pequenos ajustes tanto para o cliente quanto para o servidor, para

50
00:03:12,860 --> 00:03:15,860
que os dois possam se comunicar uns com os outros.

51
00:03:15,860 --> 00:03:21,020
Um aspecto que eu não lidei no exercício anteriormente,

52
00:03:21,020 --> 00:03:26,445
é como o servidor irá lidar com os parâmetros de consulta que vêm do lado do cliente.

53
00:03:26,445 --> 00:03:27,970
Então, como percebemos,

54
00:03:27,970 --> 00:03:31,925
quando o lado do cliente envia um pedido para

55
00:03:31,925 --> 00:03:37,360
um prato em destaque ou um líder em destaque ou uma promoção de recurso,

56
00:03:37,360 --> 00:03:41,665
vimos que o URL inclui pratos,

57
00:03:41,665 --> 00:03:45,095
recurso de ponto de interrogação é igual a verdadeiro na

58
00:03:45,095 --> 00:03:48,840
URL da solicitação que vem do lado do cliente.

59
00:03:48,840 --> 00:03:51,670
Agora, nos dados do lado do servidor,

60
00:03:51,670 --> 00:03:54,040
já vimos que o prato, a

61
00:03:54,040 --> 00:03:56,090
promoção ou o líder,

62
00:03:56,090 --> 00:03:59,835
inclui o sinalizador de recurso já nos dados JSON.

63
00:03:59,835 --> 00:04:02,975
Então, quando esta solicitação vem para o lado do servidor,

64
00:04:02,975 --> 00:04:10,285
em seguida, o servidor deve ser capaz de extrair este parâmetro de consulta a partir da solicitação de entrada

65
00:04:10,285 --> 00:04:16,865
e, em seguida, fazer apropriadamente a consulta

66
00:04:16,865 --> 00:04:24,485
do MongoDB e, em seguida, obter apenas os resultados onde este sinalizador de destaque é definido como true.

67
00:04:24,485 --> 00:04:26,365
Então, para fazer isso como vimos,

68
00:04:26,365 --> 00:04:36,380
o URL que é usado para enviar a solicitação para o servidor é /dish? feature=true.

69
00:04:36,380 --> 00:04:42,365
Então, é assim que vamos fornecer os parâmetros de consulta para o nosso lado do servidor.

70
00:04:42,365 --> 00:04:47,510
Agora, além disso, quando esta informação é recebida no lado do servidor,

71
00:04:47,510 --> 00:04:51,890
agora, vimos que antes quando fizemos o pedido get no lado do servidor,

72
00:04:51,890 --> 00:04:56,975
nós simplesmente disse pratos encontrar e, em seguida, iria encontrar todos os pratos e, em seguida, retorná-los

73
00:04:56,975 --> 00:05:03,675
quando o pedido get é enviado para o DishRouterRoute/.

74
00:05:03,675 --> 00:05:09,470
A mesma lógica se aplica tanto ao roteador promocional quanto ao roteador líder.

75
00:05:09,470 --> 00:05:14,805
Agora, quando você inclui um parâmetro de consulta como esse na URL,

76
00:05:14,805 --> 00:05:19,270
como nosso servidor será capaz de extrair esse parâmetro de consulta?

77
00:05:19,270 --> 00:05:22,730
Então, é aqui que quando a solicitação de entrada tem

78
00:05:22,730 --> 00:05:27,055
esse parâmetro de consulta anexado à URL de entrada,

79
00:05:27,055 --> 00:05:31,835
o servidor express processará automaticamente isso e transformará isso em

80
00:05:31,835 --> 00:05:38,910
um objeto JSON que é carregado em uma mensagem de solicitação que entra no lado do servidor.

81
00:05:38,910 --> 00:05:45,185
Agora, isso está disponível no lado do servidor na forma de req.query.

82
00:05:45,185 --> 00:05:49,665
Assim, quaisquer parâmetros de consulta que você incluir na URL,

83
00:05:49,665 --> 00:05:56,860
serão transformados em objetos JSON correspondentes com as informações definidas como mostrado aqui,

84
00:05:56,860 --> 00:06:01,350
e então carregados no objeto request no lado do servidor.

85
00:06:01,350 --> 00:06:04,670
Então, usando req.query no lado do servidor,

86
00:06:04,670 --> 00:06:08,105
seremos capazes de obter esses parâmetros de consulta.

87
00:06:08,105 --> 00:06:11,840
Então, quando você executa uma solicitação get no lado do servidor,

88
00:06:11,840 --> 00:06:18,635
você diz dishes.find e, em seguida, você incluir o req.query no achado lá.

89
00:06:18,635 --> 00:06:25,040
Então, assim, quando o MongoDB é consultado, então,

90
00:06:25,040 --> 00:06:31,160
apenas esses registros ou apenas aqueles documentos para os quais o destaque é definido como true serão

91
00:06:31,160 --> 00:06:38,270
extraídos do MongoDB e fornecidos de volta para nós dentro deste método get aqui,

92
00:06:38,270 --> 00:06:41,625
e então, pode ser retornado para o lado do cliente.

93
00:06:41,625 --> 00:06:49,745
Então, isso é tão simples quanto isso em lidar com os parâmetros de consulta em nosso lado do servidor.

94
00:06:49,745 --> 00:06:55,135
Então, esta atualização vamos fazer tanto para o roteador prato,

95
00:06:55,135 --> 00:07:01,225
o roteador promocional e o roteador líder no nosso lado do servidor.

96
00:07:01,225 --> 00:07:04,880
A próxima parte é, naturalmente, a autenticação do usuário.

97
00:07:04,880 --> 00:07:07,530
Então, como percebemos no lado do servidor,

98
00:07:07,530 --> 00:07:11,095
já temos esses endpoints da API REST,

99
00:07:11,095 --> 00:07:13,780
que são úteis para autenticação do usuário.

100
00:07:13,780 --> 00:07:18,855
Em particular, quando você faz uma postagem para /users/login,

101
00:07:18,855 --> 00:07:22,040
com o nome de usuário e senha, então,

102
00:07:22,040 --> 00:07:26,140
você será capaz de autenticar o usuário no lado do servidor.

103
00:07:26,140 --> 00:07:30,535
Agora, quando o usuário é autenticado no lado do servidor com êxito,

104
00:07:30,535 --> 00:07:35,059
a mensagem de resposta vinda do lado do servidor incluirá

105
00:07:35,059 --> 00:07:43,345
o token da Web JSON no corpo da resposta da mensagem de resposta recebida do lado do servidor.

106
00:07:43,345 --> 00:07:44,810
Então, no lado do cliente,

107
00:07:44,810 --> 00:07:49,210
devemos ser capazes de extrair este token e, em seguida, usar este token posteriormente.

108
00:07:49,210 --> 00:07:52,700
Assim, quando o cliente recebe a mensagem de resposta do

109
00:07:52,700 --> 00:07:57,140
lado do servidor e o usuário é autenticado com êxito no lado do servidor,

110
00:07:57,140 --> 00:07:59,690
a mensagem de resposta conterá o token da Web JSON,

111
00:07:59,690 --> 00:08:02,290
que deve ser extraído, e depois disso,

112
00:08:02,290 --> 00:08:05,240
o cliente deve incluir este token da Web JSON

113
00:08:05,240 --> 00:08:10,620
no cabeçalho de autorização para cada solicitação de saída do lado do cliente.

114
00:08:10,620 --> 00:08:13,585
Então, como lidamos com todo esse conjunto de operações?

115
00:08:13,585 --> 00:08:15,800
Agora, é aqui que vamos implementar

116
00:08:15,800 --> 00:08:20,255
outro serviço que será usado no lado do nosso cliente,

117
00:08:20,255 --> 00:08:21,720
em nosso cliente Angular,

118
00:08:21,720 --> 00:08:23,810
chamado de serviço de autenticação,

119
00:08:23,810 --> 00:08:30,185
e é aí que vamos lidar com todo o login e as operações de logout.

120
00:08:30,185 --> 00:08:33,850
Agora, o processo de logout é bastante simples, mas,

121
00:08:33,850 --> 00:08:37,840
se destruirmos o token da Web JSON que temos no lado do cliente,

122
00:08:37,840 --> 00:08:41,160
então o cliente não será mais capaz de acessar o servidor.

123
00:08:41,160 --> 00:08:43,850
Então, é tão simples quanto destruir

124
00:08:43,850 --> 00:08:48,095
o token da Web JSON no lado do cliente para fazer logout desse cliente.

125
00:08:48,095 --> 00:08:50,460
Então, dado esse entendimento,

126
00:08:50,460 --> 00:08:54,110
vamos ver as etapas que estão envolvidas em

127
00:08:54,110 --> 00:08:59,760
fazer a autenticação do usuário e lidar com a autenticação do usuário no lado do cliente.

128
00:08:59,760 --> 00:09:03,320
Então, para lidar com a autenticação do usuário no lado do cliente,

129
00:09:03,320 --> 00:09:08,945
o cliente enviará uma solicitação de postagem para o endpoint /users/login,

130
00:09:08,945 --> 00:09:14,110
e o corpo da solicitação de postagem conterá o nome de usuário e a senha.

131
00:09:14,110 --> 00:09:16,660
Neste caso, estamos usando a autenticação de login.

132
00:09:16,660 --> 00:09:18,650
Agora, para autenticação no Facebook novamente,

133
00:09:18,650 --> 00:09:22,355
essa é uma configuração diferente que eu não vou discutir agora.

134
00:09:22,355 --> 00:09:26,465
Mas, o corpo da solicitação como você verá para autenticação local,

135
00:09:26,465 --> 00:09:28,730
conterá o nome de usuário e a senha.

136
00:09:28,730 --> 00:09:33,170
Assim, quando o usuário é autenticado com êxito no lado do servidor,

137
00:09:33,170 --> 00:09:36,410
o servidor responderá de volta

138
00:09:36,410 --> 00:09:41,425
ao cliente, incluindo o token da Web JSON na mensagem de resposta.

139
00:09:41,425 --> 00:09:46,070
Então, quando o cliente recebe a mensagem de resposta do lado do servidor,

140
00:09:46,070 --> 00:09:49,790
o cliente terá que capturar esse token da Web JSON

141
00:09:49,790 --> 00:09:55,025
e, em seguida, salvar o token da Web JSON no armazenamento local no lado do cliente.

142
00:09:55,025 --> 00:10:01,250
Posteriormente, o cliente deve incluir este token em cada solicitação de saída.

143
00:10:01,250 --> 00:10:04,455
Então, como isso é feito no lado do cliente?

144
00:10:04,455 --> 00:10:06,155
Em primeiro lugar, é claro,

145
00:10:06,155 --> 00:10:11,980
você precisa salvar o token da Web JSON de entrada no armazenamento local,

146
00:10:11,980 --> 00:10:16,790
e isso é feito no serviço de autenticação que implementaremos no lado do cliente.

147
00:10:16,790 --> 00:10:19,975
Agora, para cada solicitação de saída,

148
00:10:19,975 --> 00:10:22,850
o cliente incluirá esse token no cabeçalho,

149
00:10:22,850 --> 00:10:27,100
o cabeçalho de autorização da solicitação de saída.

150
00:10:27,100 --> 00:10:28,555
Agora, como isso é feito?

151
00:10:28,555 --> 00:10:33,935
Então, este é o lugar onde nós vamos pegar a ajuda de um interceptor HTTP,

152
00:10:33,935 --> 00:10:37,265
que o HttpClient em Angular suporta.

153
00:10:37,265 --> 00:10:39,675
Então, com o interceptor HTTP,

154
00:10:39,675 --> 00:10:42,305
o interceptor nos permite interceptar

155
00:10:42,305 --> 00:10:45,875
todas as mensagens de solicitação de saída ou até mesmo

156
00:10:45,875 --> 00:10:50,010
interceptar todas as mensagens de resposta recebidas se você assim escolher.

157
00:10:50,010 --> 00:10:52,175
Mas no aplicativo Angular,

158
00:10:52,175 --> 00:10:56,215
vamos implementar o interceptor de solicitação,

159
00:10:56,215 --> 00:10:59,540
que vou ilustrar no exercício mais tarde.

160
00:10:59,540 --> 00:11:02,460
No interceptor de solicitação HTTP,

161
00:11:02,460 --> 00:11:04,375
quando a mensagem de solicitação é interceptada,

162
00:11:04,375 --> 00:11:09,915
cada mensagem de solicitação de saída será interceptada e, em seguida, o token da Web JSON

163
00:11:09,915 --> 00:11:15,650
será inserido no cabeçalho de autorização da mensagem de solicitação.

164
00:11:15,650 --> 00:11:20,290
Em seguida, a mensagem de solicitação seria passada para o lado do servidor.

165
00:11:20,290 --> 00:11:26,825
Assim, cada solicitação de saída depois que o usuário é autenticado no lado do servidor,

166
00:11:26,825 --> 00:11:30,620
cada solicitação de saída do lado do cliente carregará

167
00:11:30,620 --> 00:11:35,590
o token da Web JSON no cabeçalho de autorização da solicitação de saída.

168
00:11:35,590 --> 00:11:38,600
Agora, uma vez que o cliente logout,

169
00:11:38,600 --> 00:11:42,595
o token da Web JSON será destruído no lado do cliente.

170
00:11:42,595 --> 00:11:47,215
Então, depois disso, as solicitações de saída não conterão mais o token da Web JSON,

171
00:11:47,215 --> 00:11:50,160
porque o token da Web JSON não existe no lado do cliente.

172
00:11:50,160 --> 00:11:53,240
Então, assim, o usuário perde a autenticação.

173
00:11:53,240 --> 00:12:00,030
Então, é assim que vamos lidar com o processo de login e logout no lado do cliente,

174
00:12:00,030 --> 00:12:02,290
comunicando-se com o servidor

175
00:12:02,290 --> 00:12:04,225
e, em seguida, obter o token da web JSON,

176
00:12:04,225 --> 00:12:08,845
e, em seguida, incluindo o token da web JSON em cada solicitação de saída.

177
00:12:08,845 --> 00:12:14,250
Agora, com essa compreensão de como o cliente e o servidor irão interagir,

178
00:12:14,250 --> 00:12:18,205
vamos agora prosseguir para os próximos dois exercícios.

179
00:12:18,205 --> 00:12:22,540
Primeiro, atualizaremos o lado do servidor com algumas adições,

180
00:12:22,540 --> 00:12:28,220
para que ele possa se integrar bem com nosso site cliente.

181
00:12:28,220 --> 00:12:32,750
Depois disso, vamos atualizar o lado do cliente ou melhor, eu vou dar-lhe

182
00:12:32,750 --> 00:12:36,215
um aplicativo cliente de pleno direito que eu

183
00:12:36,215 --> 00:12:40,795
tirei do curso Angular anterior e, em seguida, eu vou atualizá-lo, o

184
00:12:40,795 --> 00:12:45,875
que também nos fornece a capacidade de usar interceptores HTTP

185
00:12:45,875 --> 00:12:51,595
em ambos os pedidos de saída e no mensagens de resposta recebidas.

186
00:12:51,595 --> 00:12:56,090
Então, vamos lidar com ambos nos próximos dois exercícios,

187
00:12:56,090 --> 00:12:58,370
e no final, você vai entender como

188
00:12:58,370 --> 00:13:02,530
integrar seu cliente e o lado do servidor.