1
00:00:00,000 --> 00:00:05,340
Ahora que hemos

2
00:00:05,340 --> 00:00:11,610
completado la implementación del servidor REST API usando Express y MongoDB en este curso,

3
00:00:11,610 --> 00:00:14,990
el siguiente pensamiento inmediato que podría ocurrir en su mente es,

4
00:00:14,990 --> 00:00:18,555
ya que ya hemos desarrollado las aplicaciones cliente, ya

5
00:00:18,555 --> 00:00:21,460
sea la aplicación Angular, la aplicación Ionic,

6
00:00:21,460 --> 00:00:25,380
o la Aplicación Native Script en los cursos anteriores,

7
00:00:25,380 --> 00:00:29,820
¿cómo integramos los dos juntos para que nuestra aplicación cliente pueda

8
00:00:29,820 --> 00:00:35,780
interactuar con el servidor API REST completo que hemos desarrollado en este curso? Por lo

9
00:00:35,780 --> 00:00:39,605
tanto, esto es lo que examinaremos en esta lección,

10
00:00:39,605 --> 00:00:44,715
en esta conferencia, y los dos ejercicios que siguen a esta conferencia.

11
00:00:44,715 --> 00:00:46,655
Por lo tanto, al final de esta lección,

12
00:00:46,655 --> 00:00:49,295
tendrá un cliente angular que

13
00:00:49,295 --> 00:00:52,220
podremos comunicarnos con el servidor que acaba de desarrollar en

14
00:00:52,220 --> 00:00:55,265
este curso y poder admitir

15
00:00:55,265 --> 00:01:01,410
la vista completa del lado del cliente de toda nuestra aplicación.

16
00:01:01,410 --> 00:01:03,860
Así, de esa manera, veremos que hemos desarrollado

17
00:01:03,860 --> 00:01:11,150
la aplicación completa de extremo a extremo desde el lado del cliente hasta el lado del servidor.

18
00:01:11,150 --> 00:01:13,895
Un enfoque similar también se puede usar con

19
00:01:13,895 --> 00:01:17,290
su cliente Ionic o con su cliente de script nativo,

20
00:01:17,290 --> 00:01:20,430
dado el hecho de que tanto el script iónico como el nativo se han

21
00:01:20,430 --> 00:01:24,420
desarrollado con el motor angular detrás de escena.

22
00:01:24,420 --> 00:01:31,100
Por lo tanto, llevar a cabo un conjunto similar de pasos debe ser capaz de hacer que su cliente Ionic y también

23
00:01:31,100 --> 00:01:35,240
su cliente de script nativo se comuniquen con el

24
00:01:35,240 --> 00:01:40,295
servidor API de descanso Express plus MongoDB que hemos desarrollado en este curso.

25
00:01:40,295 --> 00:01:43,415
Para integrar el cliente y el servidor,

26
00:01:43,415 --> 00:01:44,810
como nos hemos dado cuenta,

27
00:01:44,810 --> 00:01:50,020
nuestro servidor ya está implementado para admitir la API REST completa.

28
00:01:50,020 --> 00:01:51,695
Desde nuestro lado del cliente,

29
00:01:51,695 --> 00:01:53,240
ya sea el cliente angular,

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

31
00:01:55,750 --> 00:02:00,740
todos interactúan con el servidor utilizando los extremos de la API REST.

32
00:02:00,740 --> 00:02:06,135
Por lo tanto, cuando el cliente envía la solicitud al servidor en el punto final de la API REST,

33
00:02:06,135 --> 00:02:10,729
el servidor responderá con los datos JSON correspondientes al cliente,

34
00:02:10,729 --> 00:02:16,720
y el cliente puede hacer uso de los datos JSON para renderizar las vistas para el usuario.

35
00:02:16,720 --> 00:02:22,970
Por lo tanto, dada esta comprensión de la comunicación entre el cliente y

36
00:02:22,970 --> 00:02:25,780
el servidor, la integración debe ser bastante sencilla.

37
00:02:25,780 --> 00:02:26,960
Pero, por supuesto,

38
00:02:26,960 --> 00:02:30,820
cuando desarrollamos nuestro cliente Angular o Ionic o NativeScript,

39
00:02:30,820 --> 00:02:34,990
no hicimos la parte completa de autenticación de usuario,

40
00:02:34,990 --> 00:02:38,225
porque no teníamos eso en nuestro servidor JSON.

41
00:02:38,225 --> 00:02:43,250
Ahora que tenemos la autenticación de usuario integrada en nuestro lado del servidor,

42
00:02:43,250 --> 00:02:47,810
necesitamos actualizar nuestras aplicaciones cliente para

43
00:02:47,810 --> 00:02:52,970
permitirles realizar la autenticación de usuario en el lado del servidor,

44
00:02:52,970 --> 00:02:56,660
publicando la información de inicio de sesión en el servidor y luego

45
00:02:56,660 --> 00:03:01,190
obteniendo el token de autenticación desde el lado del servidor,

46
00:03:01,190 --> 00:03:04,400
y posteriormente, comunicarse con el servidor incluyendo

47
00:03:04,400 --> 00:03:08,175
el token de autenticación en el encabezado de los mensajes de solicitud.

48
00:03:08,175 --> 00:03:10,130
Por lo tanto, todo esto significa que tenemos que hacer

49
00:03:10,130 --> 00:03:12,860
ajustes menores tanto en el cliente como en el servidor,

50
00:03:12,860 --> 00:03:15,860
para que los dos puedan comunicarse entre sí.

51
00:03:15,860 --> 00:03:21,020
Un aspecto que no he tratado anteriormente en el ejercicio

52
00:03:21,020 --> 00:03:26,445
es cómo el servidor manejará los parámetros de consulta que vienen desde el lado del cliente.

53
00:03:26,445 --> 00:03:27,970
Entonces, como nos dimos cuenta,

54
00:03:27,970 --> 00:03:31,925
cuando el lado del cliente envía una solicitud de

55
00:03:31,925 --> 00:03:37,360
un plato destacado o un líder destacado o una promoción de características,

56
00:03:37,360 --> 00:03:41,665
vimos que la URL incluye platos, la

57
00:03:41,665 --> 00:03:45,095
característica de signo de interrogación es igual a verdadera en

58
00:03:45,095 --> 00:03:48,840
la URL de solicitud que proviene del lado del cliente.

59
00:03:48,840 --> 00:03:51,670
Ahora, en los datos en el lado del servidor,

60
00:03:51,670 --> 00:03:54,040
ya vimos que el plato,

61
00:03:54,040 --> 00:03:56,090
la promoción o el líder,

62
00:03:56,090 --> 00:03:59,835
incluye el indicador de característica ya en los datos JSON.

63
00:03:59,835 --> 00:04:02,975
Por lo tanto, cuando esta solicitud llega al lado del servidor,

64
00:04:02,975 --> 00:04:10,285
entonces el servidor debería poder extraer este parámetro de consulta de la solicitud entrante,

65
00:04:10,285 --> 00:04:16,865
y luego hacer apropiadamente la consulta

66
00:04:16,865 --> 00:04:24,485
del MongoDB y luego obtener solo los resultados donde este indicador destacado se establece en true.

67
00:04:24,485 --> 00:04:26,365
Entonces, para hacer eso como vimos,

68
00:04:26,365 --> 00:04:36,380
la URL que se usa para enviar la solicitud al servidor es /dish? feature=true.

69
00:04:36,380 --> 00:04:42,365
Por lo tanto, así es como proporcionaremos los parámetros de consulta a nuestro lado del servidor.

70
00:04:42,365 --> 00:04:47,510
Ahora, además, cuando esta información se recibe en el lado del servidor,

71
00:04:47,510 --> 00:04:51,890
ahora, vimos que antes cuando hicimos la solicitud de obtener en el lado del servidor,

72
00:04:51,890 --> 00:04:56,975
simplemente dijimos que los platos encuentran y luego encontraríamos todos los platos y luego los devolveríamos

73
00:04:56,975 --> 00:05:03,675
cuando la solicitud de obtener se envía al DishRouterRoute/.

74
00:05:03,675 --> 00:05:09,470
La misma lógica se aplica tanto al enrutador promocional como al enrutador líder.

75
00:05:09,470 --> 00:05:14,805
Ahora, cuando incluye un parámetro de consulta como ese en la URL,

76
00:05:14,805 --> 00:05:19,270
¿cómo nuestro lado del servidor podrá extraer este parámetro de consulta?

77
00:05:19,270 --> 00:05:22,730
Entonces, aquí es donde cuando la solicitud entrante tiene

78
00:05:22,730 --> 00:05:27,055
este parámetro de consulta adjunto a la URL entrante,

79
00:05:27,055 --> 00:05:31,835
el servidor express procesará automáticamente eso y lo convertirá en

80
00:05:31,835 --> 00:05:38,910
un objeto JSON que se carga en un mensaje de solicitud que viene en el lado del servidor.

81
00:05:38,910 --> 00:05:45,185
Ahora, esto está disponible en el lado del servidor en forma de req.query. Por lo

82
00:05:45,185 --> 00:05:49,665
tanto, cualesquiera que sean los parámetros de consulta que incluya en la URL,

83
00:05:49,665 --> 00:05:56,860
se convertirán en objetos JSON correspondientes con la información establecida como se muestra aquí,

84
00:05:56,860 --> 00:06:01,350
y luego se cargarán en el objeto de solicitud en el lado del servidor.

85
00:06:01,350 --> 00:06:04,670
Por lo tanto, mediante el uso de req.query en el lado del servidor,

86
00:06:04,670 --> 00:06:08,105
podremos obtener estos parámetros de consulta.

87
00:06:08,105 --> 00:06:11,840
Por lo tanto, cuando realiza una solicitud get en el lado del servidor,

88
00:06:11,840 --> 00:06:18,635
dice dishes.find y luego incluye el req.query en el hallazgo allí.

89
00:06:18,635 --> 00:06:25,040
Entonces, por lo tanto, cuando se consulta el MongoDB, entonces,

90
00:06:25,040 --> 00:06:31,160
solo aquellos registros o solo aquellos documentos para los que el destacado se establece en verdadero serán

91
00:06:31,160 --> 00:06:38,270
extraídos del MongoDB y proporcionados de nuevo a nosotros dentro de este método get aquí,

92
00:06:38,270 --> 00:06:41,625
y luego, pueden ser devueltos al lado del cliente.

93
00:06:41,625 --> 00:06:49,745
Por lo tanto, esto es tan simple como eso en el manejo de los parámetros de consulta en nuestro lado del servidor.

94
00:06:49,745 --> 00:06:55,135
Por lo tanto, esta actualización haremos tanto al enrutador de plato,

95
00:06:55,135 --> 00:07:01,225
al enrutador promocional y al enrutador líder en nuestro lado del servidor.

96
00:07:01,225 --> 00:07:04,880
La siguiente parte es, por supuesto, la autenticación del usuario.

97
00:07:04,880 --> 00:07:07,530
Por lo tanto, como nos hemos dado cuenta en el lado del servidor,

98
00:07:07,530 --> 00:07:11,095
ya tenemos estos puntos finales de API REST,

99
00:07:11,095 --> 00:07:13,780
que son útiles para la autenticación del usuario.

100
00:07:13,780 --> 00:07:18,855
En particular, cuando usted hace una publicación a /users/login,

101
00:07:18,855 --> 00:07:22,040
con el nombre de usuario y la contraseña, entonces,

102
00:07:22,040 --> 00:07:26,140
usted será capaz de autenticar al usuario en el lado del servidor.

103
00:07:26,140 --> 00:07:30,535
Ahora, cuando el usuario se autentica correctamente en el lado del servidor,

104
00:07:30,535 --> 00:07:35,059
el mensaje de respuesta proveniente del lado del servidor incluirá

105
00:07:35,059 --> 00:07:43,345
el token web JSON en el cuerpo de respuesta del mensaje de respuesta entrante desde el lado del servidor.

106
00:07:43,345 --> 00:07:44,810
Por lo tanto, en el lado del cliente,

107
00:07:44,810 --> 00:07:49,210
deberíamos poder extraer este token y luego usar este token posteriormente.

108
00:07:49,210 --> 00:07:52,700
Por lo tanto, cuando el cliente recibe el mensaje de respuesta

109
00:07:52,700 --> 00:07:57,140
del lado del servidor y el usuario se autentica correctamente en el lado del servidor,

110
00:07:57,140 --> 00:07:59,690
el mensaje de respuesta contendrá el token web JSON,

111
00:07:59,690 --> 00:08:02,290
que debe extraerse, y a partir de entonces,

112
00:08:02,290 --> 00:08:05,240
el cliente debe incluir este token web JSON en

113
00:08:05,240 --> 00:08:10,620
el para cada solicitud saliente desde el lado del cliente.

114
00:08:10,620 --> 00:08:13,585
Entonces, ¿cómo manejamos todo este conjunto de operaciones?

115
00:08:13,585 --> 00:08:15,800
Ahora, aquí es donde implementaremos

116
00:08:15,800 --> 00:08:20,255
otro servicio que será utilizado en nuestro lado cliente,

117
00:08:20,255 --> 00:08:21,720
en nuestro cliente Angular,

118
00:08:21,720 --> 00:08:23,810
llamado el servicio de autenticación,

119
00:08:23,810 --> 00:08:30,185
y ahí es donde manejaremos todas las operaciones de inicio de sesión y cierre de sesión.

120
00:08:30,185 --> 00:08:33,850
Ahora, el proceso de cierre de sesión es bastante sencillo pero,

121
00:08:33,850 --> 00:08:37,840
si destruimos el token web JSON que tenemos en el lado

122
00:08:37,840 --> 00:08:41,160
del cliente, entonces el cliente ya no podrá acceder al servidor.

123
00:08:41,160 --> 00:08:43,850
Por lo tanto, es tan simple como simplemente destruir

124
00:08:43,850 --> 00:08:48,095
el token web JSON en el lado del cliente para cerrar sesión en ese cliente.

125
00:08:48,095 --> 00:08:50,460
Por lo tanto, teniendo en cuenta esta comprensión,

126
00:08:50,460 --> 00:08:54,110
veamos los pasos que están involucrados en

127
00:08:54,110 --> 00:08:59,760
hacer la autenticación del usuario y manejar la autenticación del usuario en el lado del cliente.

128
00:08:59,760 --> 00:09:03,320
Por lo tanto, para manejar la autenticación del usuario en el lado

129
00:09:03,320 --> 00:09:08,945
del cliente, el cliente enviará una solicitud de publicación al endpoint /users/login,

130
00:09:08,945 --> 00:09:14,110
y el cuerpo de la solicitud de publicación contendrá el nombre de usuario y la contraseña.

131
00:09:14,110 --> 00:09:16,660
Estamos utilizando la autenticación de inicio de sesión en este caso.

132
00:09:16,660 --> 00:09:18,650
Ahora, para la autenticación de Facebook de nuevo,

133
00:09:18,650 --> 00:09:22,355
esa es una configuración diferente que no voy a discutir en este momento.

134
00:09:22,355 --> 00:09:26,465
Pero, el cuerpo de la solicitud como verá para la autenticación local,

135
00:09:26,465 --> 00:09:28,730
contendrá el nombre de usuario y la contraseña.

136
00:09:28,730 --> 00:09:33,170
Por lo tanto, cuando el usuario se autentica correctamente en el lado

137
00:09:33,170 --> 00:09:36,410
del servidor, el servidor responderá de nuevo

138
00:09:36,410 --> 00:09:41,425
al cliente incluyendo el token web JSON en el mensaje de respuesta.

139
00:09:41,425 --> 00:09:46,070
Por lo tanto, cuando el cliente recibe el mensaje de respuesta desde el lado del servidor,

140
00:09:46,070 --> 00:09:49,790
entonces el cliente tendrá que capturar este token web JSON

141
00:09:49,790 --> 00:09:55,025
y luego guardar el token web JSON en el almacenamiento local en el lado del cliente.

142
00:09:55,025 --> 00:10:01,250
A partir de entonces, el cliente debe incluir este token en cada solicitud saliente.

143
00:10:01,250 --> 00:10:04,455
Entonces, ¿cómo se logra esto en el lado del cliente?

144
00:10:04,455 --> 00:10:06,155
En primer lugar, por supuesto,

145
00:10:06,155 --> 00:10:11,980
debe guardar el token web JSON entrante en el almacenamiento local,

146
00:10:11,980 --> 00:10:16,790
y eso se hace en el servicio de autenticación que implementaremos en el lado del cliente.

147
00:10:16,790 --> 00:10:19,975
Ahora, para cada solicitud saliente,

148
00:10:19,975 --> 00:10:22,850
el cliente incluirá este token en el encabezado,

149
00:10:22,850 --> 00:10:27,100
el encabezado de autorización de la solicitud saliente.

150
00:10:27,100 --> 00:10:28,555
Ahora, ¿cómo se logra esto?

151
00:10:28,555 --> 00:10:33,935
Entonces, aquí es donde vamos a tomar la ayuda de un interceptor HTTP,

152
00:10:33,935 --> 00:10:37,265
que el HttpClient en Angular soporta.

153
00:10:37,265 --> 00:10:39,675
Por lo tanto, con el interceptor HTTP,

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

155
00:10:42,305 --> 00:10:45,875
cada mensaje de solicitud saliente o incluso

156
00:10:45,875 --> 00:10:50,010
interceptar cada mensaje de respuesta entrante si así lo desea.

157
00:10:50,010 --> 00:10:52,175
Pero en la aplicación Angular,

158
00:10:52,175 --> 00:10:56,215
vamos a implementar el interceptor de solicitudes,

159
00:10:56,215 --> 00:10:59,540
que ilustraré en el ejercicio más adelante.

160
00:10:59,540 --> 00:11:02,460
En el interceptor de solicitudes HTTP,

161
00:11:02,460 --> 00:11:04,375
cuando se intercepta el mensaje de solicitud,

162
00:11:04,375 --> 00:11:09,915
cada mensaje de solicitud saliente será interceptado y luego el token web JSON

163
00:11:09,915 --> 00:11:15,650
se insertará en el encabezado de autorización del mensaje de solicitud.

164
00:11:15,650 --> 00:11:20,290
Luego, a partir de entonces, el mensaje de solicitud se transmitiría al lado del servidor. Por

165
00:11:20,290 --> 00:11:26,825
lo tanto, cada solicitud saliente después de que el usuario se autentica en el lado del servidor,

166
00:11:26,825 --> 00:11:30,620
cada solicitud saliente del lado del cliente llevará

167
00:11:30,620 --> 00:11:35,590
el token web JSON en el encabezado de autorización de la solicitud saliente.

168
00:11:35,590 --> 00:11:38,600
Ahora, una vez que el cliente cierra la sesión,

169
00:11:38,600 --> 00:11:42,595
el token web JSON se destruirá en el lado del cliente.

170
00:11:42,595 --> 00:11:47,215
Por lo tanto, a partir de entonces, las solicitudes salientes ya no contendrán el token web

171
00:11:47,215 --> 00:11:50,160
JSON, porque el token web JSON no existe en el lado del cliente.

172
00:11:50,160 --> 00:11:53,240
Por lo tanto, el usuario pierde la autenticación.

173
00:11:53,240 --> 00:12:00,030
Entonces, así es como manejaremos el proceso de inicio de sesión y cierre de sesión en el lado del cliente,

174
00:12:00,030 --> 00:12:02,290
comunicándonos con el servidor,

175
00:12:02,290 --> 00:12:04,225
y luego obtendremos el token web JSON,

176
00:12:04,225 --> 00:12:08,845
y luego incluiremos el token web JSON en cada solicitud saliente.

177
00:12:08,845 --> 00:12:14,250
Ahora, con esta comprensión de cómo interactuarán el cliente y el servidor,

178
00:12:14,250 --> 00:12:18,205
procedamos ahora a los siguientes dos ejercicios.

179
00:12:18,205 --> 00:12:22,540
Primero, actualizaremos el lado del servidor con algunas adiciones,

180
00:12:22,540 --> 00:12:28,220
para que pueda integrarse bien con nuestro sitio cliente.

181
00:12:28,220 --> 00:12:32,750
A partir de entonces, actualizaremos el lado del cliente o más bien le daré

182
00:12:32,750 --> 00:12:36,215
una aplicación cliente completa que he

183
00:12:36,215 --> 00:12:40,795
tomado del curso Angular anterior y luego la actualizaré, lo

184
00:12:40,795 --> 00:12:45,875
que también nos proporciona la capacidad de usar interceptores HTTP

185
00:12:45,875 --> 00:12:51,595
tanto en las solicitudes salientes como en el mensajes de respuesta entrantes.

186
00:12:51,595 --> 00:12:56,090
Por lo tanto, trataremos ambos en los próximos dos ejercicios,

187
00:12:56,090 --> 00:12:58,370
y al final, comprenderá cómo

188
00:12:58,370 --> 00:13:02,530
integrar su cliente y el lado del servidor.