1
00:00:03,650 --> 00:00:06,795
Agora que concluímos

2
00:00:06,795 --> 00:00:11,395
a implementação do servidor REST API usando Express e MongoDB neste curso,

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

4
00:00:14,990 --> 00:00:20,490
uma vez que já desenvolvemos os aplicativos cliente nos cursos anteriores,

5
00:00:20,490 --> 00:00:24,930
como integramos os dois juntos para que o nosso é capaz de

6
00:00:24,930 --> 00:00:30,880
interagir com o servidor API REST completo que desenvolvemos neste curso?

7
00:00:30,880 --> 00:00:33,820
Então, isto é o que vamos examinar

8
00:00:33,820 --> 00:00:39,820
nesta palestra e os dois exercícios que se seguem a esta palestra.

9
00:00:39,820 --> 00:00:41,770
Então, no final desta lição,

10
00:00:41,770 --> 00:00:44,390
você terá React Client que

11
00:00:44,390 --> 00:00:47,330
poderá se comunicar com o servidor que você acabou de desenvolver

12
00:00:47,330 --> 00:00:50,345
neste curso e ser capaz de suportar

13
00:00:50,345 --> 00:00:56,510
a visão completa do lado do cliente de toda a nossa aplicação.

14
00:00:56,510 --> 00:00:58,970
Assim, vamos ver que desenvolvemos

15
00:00:58,970 --> 00:01:02,565
o

16
00:01:02,565 --> 00:01:07,795
aplicativo completo de ponta a ponta do lado do cliente todo o caminho para o lado do servidor neste curso.

17
00:01:07,795 --> 00:01:10,910
Para integrar o cliente e o servidor,

18
00:01:10,910 --> 00:01:13,670
como percebemos que nosso servidor já está

19
00:01:13,670 --> 00:01:17,525
implementado para suportar a API REST completa.

20
00:01:17,525 --> 00:01:19,220
Do lado do nosso cliente,

21
00:01:19,220 --> 00:01:20,720
seja o cliente angular,

22
00:01:20,720 --> 00:01:23,340
o cliente iônico ou o cliente de script nativo,

23
00:01:23,340 --> 00:01:28,240
todos eles interagem com o servidor usando os endpoints da API REST.

24
00:01:28,240 --> 00:01:33,630
Assim, quando o cliente envia a solicitação para o servidor no ponto final da API REST,

25
00:01:33,630 --> 00:01:38,190
o servidor responderá com os dados JSON correspondentes de volta ao cliente.

26
00:01:38,190 --> 00:01:44,225
O cliente pode então fazer uso dos dados JSON para renderizar as exibições para o usuário.

27
00:01:44,225 --> 00:01:50,450
Assim, dado este entendimento da comunicação entre o cliente e o servidor,

28
00:01:50,450 --> 00:01:53,745
a integração deve ser bastante simples.

29
00:01:53,745 --> 00:01:58,475
Agora que temos a autenticação do usuário embutida em nosso lado do servidor,

30
00:01:58,475 --> 00:02:03,330
precisamos atualizar nossos aplicativos cliente para

31
00:02:03,330 --> 00:02:08,400
habilitá-los a fazer autenticação do usuário no lado do servidor,

32
00:02:08,400 --> 00:02:12,200
postando as informações de login para o servidor e, em seguida,

33
00:02:12,200 --> 00:02:16,010
obtendo o token de autenticação

34
00:02:16,010 --> 00:02:19,120
do lado do servidor e, posteriormente, comunicando-se com o servidor

35
00:02:19,120 --> 00:02:23,700
, incluindo o token de autenticação no cabeçalho das mensagens de solicitação.

36
00:02:23,700 --> 00:02:27,050
Então, tudo isso significa que precisamos fazer pequenos ajustes tanto para

37
00:02:27,050 --> 00:02:31,345
o cliente quanto para o servidor para que os dois possam se comunicar uns com os outros.

38
00:02:31,345 --> 00:02:36,530
Um aspecto que eu não lidei anteriormente no exercício

39
00:02:36,530 --> 00:02:41,970
é como o servidor irá lidar com os parâmetros de consulta que vêm do lado do cliente.

40
00:02:41,970 --> 00:02:43,480
Então, como percebemos,

41
00:02:43,480 --> 00:02:47,450
quando o lado do cliente envia um pedido para

42
00:02:47,450 --> 00:02:53,035
um prato em destaque ou um líder em destaque ou uma promoção em destaque,

43
00:02:53,035 --> 00:02:55,910
vimos que o URL inclui,

44
00:02:55,910 --> 00:02:59,590
pratos recurso de ponto de interrogação é igual a

45
00:02:59,590 --> 00:03:04,370
verdadeiro na URL da solicitação que vem do lado do cliente.

46
00:03:04,370 --> 00:03:07,210
Agora, nos dados do lado do servidor,

47
00:03:07,210 --> 00:03:09,585
já vimos que o prato,

48
00:03:09,585 --> 00:03:15,370
a promoção ou o líder inclui a bandeira em destaque já nos dados JSON.

49
00:03:15,370 --> 00:03:18,649
Então, quando esta solicitação vem para o lado do servidor,

50
00:03:18,649 --> 00:03:21,394
em seguida, o servidor deve ser capaz de extrair

51
00:03:21,394 --> 00:03:26,765
este parâmetro de consulta a partir da solicitação de entrada e, em seguida,

52
00:03:26,765 --> 00:03:32,390
fazer adequadamente a consulta

53
00:03:32,390 --> 00:03:39,950
do MongoDB e, em seguida, obter apenas os resultados onde este sinalizador de destaque é definido como true.

54
00:03:39,950 --> 00:03:41,740
Então, para fazer isso como vimos,

55
00:03:41,740 --> 00:03:47,075
o URL que é usado para enviar a solicitação para o servidor é,

56
00:03:47,075 --> 00:03:52,030
barra pratos ponto de interrogação em destaque é igual a true.

57
00:03:52,030 --> 00:03:57,905
Então, é assim que vamos fornecer os parâmetros de consulta para o nosso lado do servidor.

58
00:03:57,905 --> 00:04:02,610
Agora, além disso, quando esta informação é recebida no lado do servidor,

59
00:04:02,610 --> 00:04:07,430
agora vimos que antes quando fizemos a solicitação get no lado do servidor,

60
00:04:07,430 --> 00:04:10,190
nós simplesmente disse pratos encontrar e, em seguida, nós iria encontrar

61
00:04:10,190 --> 00:04:13,135
todos os pratos e, em seguida, retorná-los quando

62
00:04:13,135 --> 00:04:19,745
o pedido get é enviado para a barra rota do roteador prato .

63
00:04:19,745 --> 00:04:25,185
A mesma lógica se aplica tanto ao roteador promocional quanto ao roteador líder.

64
00:04:25,185 --> 00:04:30,339
Agora, quando você inclui um parâmetro de consulta como esse na URL,

65
00:04:30,339 --> 00:04:34,695
como nosso servidor será capaz de extrair esse parâmetro de consulta?

66
00:04:34,695 --> 00:04:35,980
Então, é aqui que,

67
00:04:35,980 --> 00:04:42,590
quando a solicitação de entrada tem esse parâmetro de consulta anexado à URL de entrada,

68
00:04:42,590 --> 00:04:47,375
o servidor express processará automaticamente isso e transformará isso em

69
00:04:47,375 --> 00:04:54,445
um objeto JSON que é carregado em uma mensagem de solicitação que entra no lado do servidor.

70
00:04:54,445 --> 00:05:00,710
Agora, isso está disponível no lado do servidor na forma de req.query.

71
00:05:00,710 --> 00:05:06,545
Assim, quaisquer parâmetros de consulta que você incluir na URL serão transformados em

72
00:05:06,545 --> 00:05:11,480
objetos JSON correspondentes com as informações definidas como

73
00:05:11,480 --> 00:05:16,880
mostrado aqui e, em seguida, carregados no objeto request no lado do servidor.

74
00:05:16,880 --> 00:05:19,940
Então, usando req.query no lado do servidor,

75
00:05:19,940 --> 00:05:23,625
seremos capazes de obter esses parâmetros de consulta.

76
00:05:23,625 --> 00:05:27,935
Então, quando você executa uma solicitação get no lado do servidor você diz

77
00:05:27,935 --> 00:05:34,115
dishes.find e, em seguida, você incluir o req.query no achado lá.

78
00:05:34,115 --> 00:05:38,960
Assim, quando o MongoDB é

79
00:05:38,960 --> 00:05:44,120
consultado, em seguida, apenas esses registros ou apenas os documentos para os

80
00:05:44,120 --> 00:05:50,390
quais o destaque é definido como verdadeiro será extraído do MongoDB e fornecido de volta para

81
00:05:50,390 --> 00:05:57,020
nós dentro deste método get aqui e, em seguida, pode ser devolvido para o lado do cliente.

82
00:05:57,020 --> 00:06:05,270
Então, isso é tão simples quanto isso em lidar com os parâmetros de consulta em nosso lado do servidor.

83
00:06:05,270 --> 00:06:10,645
Então, esta atualização vamos fazer tanto para o roteador prato,

84
00:06:10,645 --> 00:06:16,880
o roteador promocional e o roteador líder no nosso lado do servidor.

85
00:06:16,880 --> 00:06:18,430
A próxima parte é,

86
00:06:18,430 --> 00:06:20,545
claro, a Autenticação do Usuário.

87
00:06:20,545 --> 00:06:22,060
Então, como percebemos,

88
00:06:22,060 --> 00:06:24,150
no lado do servidor já temos

89
00:06:24,150 --> 00:06:29,450
esses endpoints REST API que são úteis para Autenticação do Usuário,

90
00:06:29,450 --> 00:06:33,260
em particular quando você faz um post para cortar usuários

91
00:06:33,260 --> 00:06:37,100
barra login com o nome de usuário e senha,

92
00:06:37,100 --> 00:06:41,675
então você será capaz de autenticar o usuário no servidor Lado.

93
00:06:41,675 --> 00:06:46,080
Agora, quando o usuário é autenticado no lado do servidor com êxito,

94
00:06:46,080 --> 00:06:50,584
a mensagem de resposta vinda do lado do servidor incluirá

95
00:06:50,584 --> 00:06:58,880
o JSON Web Token no corpo da resposta da mensagem de resposta recebida do lado do servidor.

96
00:06:58,880 --> 00:07:00,350
Então, no lado do cliente,

97
00:07:00,350 --> 00:07:04,700
devemos ser capazes de extrair este token e, em seguida, usar este token posteriormente.

98
00:07:04,700 --> 00:07:08,210
Assim, quando o cliente recebe a mensagem de resposta do

99
00:07:08,210 --> 00:07:12,560
lado do servidor e o usuário é autenticado com êxito no lado do servidor,

100
00:07:12,560 --> 00:07:15,220
a mensagem de resposta conterá o JSON Web Token,

101
00:07:15,220 --> 00:07:16,950
que deve ser extraído,

102
00:07:16,950 --> 00:07:20,780
e, posteriormente, o cliente deve incluir este token da Web JSON

103
00:07:20,780 --> 00:07:26,200
no cabeçalho de autorização para cada solicitação de saída do lado do cliente.

104
00:07:26,200 --> 00:07:31,205
Isso é feito salvando o JSON Web Token no armazenamento local.

105
00:07:31,205 --> 00:07:35,155
Posteriormente, para cada solicitação de busca que emitimos,

106
00:07:35,155 --> 00:07:40,365
podemos configurar o cabeçalho de autorização para conter o Token da Web JSON.

107
00:07:40,365 --> 00:07:43,815
Agora, o processo de logout é bastante simples,

108
00:07:43,815 --> 00:07:47,865
se destruirmos o JSON Web Token que temos no lado do cliente,

109
00:07:47,865 --> 00:07:51,210
então o cliente não será mais capaz de acessar o servidor.

110
00:07:51,210 --> 00:07:53,930
Então, é tão simples quanto destruir

111
00:07:53,930 --> 00:07:58,180
o JSON Web Token no lado do cliente para fazer logout desse cliente.

112
00:07:58,180 --> 00:08:00,530
Então, dado esse entendimento,

113
00:08:00,530 --> 00:08:04,175
vamos ver as etapas que estão envolvidas em

114
00:08:04,175 --> 00:08:09,840
fazer a autenticação do usuário no tratamento da autenticação do usuário no lado do cliente.

115
00:08:09,840 --> 00:08:13,085
Então, para lidar com a autenticação do usuário no lado do cliente,

116
00:08:13,085 --> 00:08:19,000
o cliente enviará uma solicitação de postagem para os usuários barra barra ponto final de login,

117
00:08:19,000 --> 00:08:24,190
e o corpo da solicitação de postagem conterá o nome de usuário e senha.

118
00:08:24,190 --> 00:08:26,720
Neste caso, estamos usando a autenticação de login.

119
00:08:26,720 --> 00:08:28,695
Agora, para autenticação no Facebook, novamente,

120
00:08:28,695 --> 00:08:32,425
essa é uma configuração diferente que eu não vou discutir agora.

121
00:08:32,425 --> 00:08:35,570
Mas o corpo da solicitação como você vê para

122
00:08:35,570 --> 00:08:38,780
autenticação local conterá o nome de usuário e a senha.

123
00:08:38,780 --> 00:08:43,220
Assim, quando o usuário é autenticado com êxito no lado do servidor,

124
00:08:43,220 --> 00:08:46,460
o servidor responderá de volta

125
00:08:46,460 --> 00:08:51,490
ao cliente, incluindo o JSON Web Token na mensagem de resposta.

126
00:08:51,490 --> 00:08:56,150
Então, quando o cliente recebe a mensagem de resposta do lado do servidor,

127
00:08:56,150 --> 00:09:00,320
o cliente terá que capturar esse Token da Web JSON e,

128
00:09:00,320 --> 00:09:05,080
em seguida, salvar o Token da Web JSON no armazenamento local no lado do cliente.

129
00:09:05,080 --> 00:09:11,300
Posteriormente, o cliente deve incluir este token em cada solicitação de saída.

130
00:09:11,300 --> 00:09:14,495
Então, como isso é feito no lado do cliente?

131
00:09:14,495 --> 00:09:20,285
Em primeiro lugar, precisamos salvar o JSON Web Token no armazenamento local.

132
00:09:20,285 --> 00:09:25,670
Agora, isso é feito dentro do criador de ação que lida com o processo de login do usuário.

133
00:09:25,670 --> 00:09:32,685
Então, quando a postagem for feita no servidor do criador de indução do lado do cliente,

134
00:09:32,685 --> 00:09:36,020
a mensagem de resposta conterá o token,

135
00:09:36,020 --> 00:09:41,540
e esse token será salvo no criador da ação que lida com o processo de login do usuário.

136
00:09:41,540 --> 00:09:45,875
Agora, depois disso, quando qualquer solicitação de busca é feito,

137
00:09:45,875 --> 00:09:52,829
então podemos facilmente definir o cabeçalho de autorização na solicitação de busca de saída.

138
00:09:52,829 --> 00:09:56,005
Agora, uma vez que o cliente logout,

139
00:09:56,005 --> 00:09:59,930
o JSON Web Token será destruído no lado do cliente.

140
00:09:59,930 --> 00:10:03,050
Então, depois disso, as solicitações de saída não conterão

141
00:10:03,050 --> 00:10:07,490
mais o Token da Web JSON porque o Token da Web JSON não existe no lado do cliente.

142
00:10:07,490 --> 00:10:10,790
Assim, o usuário perde a autenticação.

143
00:10:10,790 --> 00:10:17,455
Então, é assim que vamos lidar com o login e o processo de logout no lado do cliente.

144
00:10:17,455 --> 00:10:21,890
Comunicando com o servidor e, em seguida, obter o JSON Web Token e

145
00:10:21,890 --> 00:10:26,185
, em seguida, incluindo o JSON Web Token em cada solicitação de saída.

146
00:10:26,185 --> 00:10:31,570
Agora, com essa compreensão de como o cliente e o servidor irão interagir,

147
00:10:31,570 --> 00:10:35,540
vamos agora prosseguir para os próximos dois exercícios.

148
00:10:35,540 --> 00:10:40,410
Primeiro, vamos atualizar o lado do servidor com algumas adições para

149
00:10:40,410 --> 00:10:45,550
que ele possa se integrar bem com o lado do nosso cliente.

150
00:10:45,550 --> 00:10:50,075
Depois disso, atualizaremos o lado do cliente ou melhor, eu lhe darei

151
00:10:50,075 --> 00:10:54,200
um aplicativo cliente de pleno direito que eu tirei

152
00:10:54,200 --> 00:10:58,875
da força de reação anterior e adaptei, atualizei.

153
00:10:58,875 --> 00:11:03,080
Então, vamos lidar com ambos nos próximos dois exercícios

154
00:11:03,080 --> 00:11:09,460
e, no final, você entenderá como integrar o lado do cliente e do servidor.