Ahora que hemos
completado la implementación del servidor REST API usando Express y MongoDB en este curso,
el siguiente pensamiento inmediato que podría ocurrir en su mente es,
ya que ya hemos desarrollado las aplicaciones cliente, ya
sea la aplicación Angular, la aplicación Ionic,
o la Aplicación Native Script en los cursos anteriores,
¿cómo integramos los dos juntos para que nuestra aplicación cliente pueda
interactuar con el servidor API REST completo que hemos desarrollado en este curso? Por lo
tanto, esto es lo que examinaremos en esta lección,
en esta conferencia, y los dos ejercicios que siguen a esta conferencia.
Por lo tanto, al final de esta lección,
tendrá un cliente angular que
podremos comunicarnos con el servidor que acaba de desarrollar en
este curso y poder admitir
la vista completa del lado del cliente de toda nuestra aplicación.
Así, de esa manera, veremos que hemos desarrollado
la aplicación completa de extremo a extremo desde el lado del cliente hasta el lado del servidor.
Un enfoque similar también se puede usar con
su cliente Ionic o con su cliente de script nativo,
dado el hecho de que tanto el script iónico como el nativo se han
desarrollado con el motor angular detrás de escena.
Por lo tanto, llevar a cabo un conjunto similar de pasos debe ser capaz de hacer que su cliente Ionic y también
su cliente de script nativo se comuniquen con el
servidor API de descanso Express plus MongoDB que hemos desarrollado en este curso.
Para integrar el cliente y el servidor,
como nos hemos dado cuenta,
nuestro servidor ya está implementado para admitir la API REST completa.
Desde nuestro lado del cliente,
ya sea el cliente angular,
el cliente iónico o el cliente de script nativo,
todos interactúan con el servidor utilizando los extremos de la API REST.
Por lo tanto, cuando el cliente envía la solicitud al servidor en el punto final de la API REST,
el servidor responderá con los datos JSON correspondientes al cliente,
y el cliente puede hacer uso de los datos JSON para renderizar las vistas para el usuario.
Por lo tanto, dada esta comprensión de la comunicación entre el cliente y
el servidor, la integración debe ser bastante sencilla.
Pero, por supuesto,
cuando desarrollamos nuestro cliente Angular o Ionic o NativeScript,
no hicimos la parte completa de autenticación de usuario,
porque no teníamos eso en nuestro servidor JSON.
Ahora que tenemos la autenticación de usuario integrada en nuestro lado del servidor,
necesitamos actualizar nuestras aplicaciones cliente para
permitirles realizar la autenticación de usuario en el lado del servidor,
publicando la información de inicio de sesión en el servidor y luego
obteniendo el token de autenticación desde el lado del servidor,
y posteriormente, comunicarse con el servidor incluyendo
el token de autenticación en el encabezado de los mensajes de solicitud.
Por lo tanto, todo esto significa que tenemos que hacer
ajustes menores tanto en el cliente como en el servidor,
para que los dos puedan comunicarse entre sí.
Un aspecto que no he tratado anteriormente en el ejercicio
es cómo el servidor manejará los parámetros de consulta que vienen desde el lado del cliente.
Entonces, como nos dimos cuenta,
cuando el lado del cliente envía una solicitud de
un plato destacado o un líder destacado o una promoción de características,
vimos que la URL incluye platos, la
característica de signo de interrogación es igual a verdadera en
la URL de solicitud que proviene del lado del cliente.
Ahora, en los datos en el lado del servidor,
ya vimos que el plato,
la promoción o el líder,
incluye el indicador de característica ya en los datos JSON.
Por lo tanto, cuando esta solicitud llega al lado del servidor,
entonces el servidor debería poder extraer este parámetro de consulta de la solicitud entrante,
y luego hacer apropiadamente la consulta
del MongoDB y luego obtener solo los resultados donde este indicador destacado se establece en true.
Entonces, para hacer eso como vimos,
la URL que se usa para enviar la solicitud al servidor es /dish? feature=true.
Por lo tanto, así es como proporcionaremos los parámetros de consulta a nuestro lado del servidor.
Ahora, además, cuando esta información se recibe en el lado del servidor,
ahora, vimos que antes cuando hicimos la solicitud de obtener en el lado del servidor,
simplemente dijimos que los platos encuentran y luego encontraríamos todos los platos y luego los devolveríamos
cuando la solicitud de obtener se envía al DishRouterRoute/.
La misma lógica se aplica tanto al enrutador promocional como al enrutador líder.
Ahora, cuando incluye un parámetro de consulta como ese en la URL,
¿cómo nuestro lado del servidor podrá extraer este parámetro de consulta?
Entonces, aquí es donde cuando la solicitud entrante tiene
este parámetro de consulta adjunto a la URL entrante,
el servidor express procesará automáticamente eso y lo convertirá en
un objeto JSON que se carga en un mensaje de solicitud que viene en el lado del servidor.
Ahora, esto está disponible en el lado del servidor en forma de req.query. Por lo
tanto, cualesquiera que sean los parámetros de consulta que incluya en la URL,
se convertirán en objetos JSON correspondientes con la información establecida como se muestra aquí,
y luego se cargarán en el objeto de solicitud en el lado del servidor.
Por lo tanto, mediante el uso de req.query en el lado del servidor,
podremos obtener estos parámetros de consulta.
Por lo tanto, cuando realiza una solicitud get en el lado del servidor,
dice dishes.find y luego incluye el req.query en el hallazgo allí.
Entonces, por lo tanto, cuando se consulta el MongoDB, entonces,
solo aquellos registros o solo aquellos documentos para los que el destacado se establece en verdadero serán
extraídos del MongoDB y proporcionados de nuevo a nosotros dentro de este método get aquí,
y luego, pueden ser devueltos al lado del cliente.
Por lo tanto, esto es tan simple como eso en el manejo de los parámetros de consulta en nuestro lado del servidor.
Por lo tanto, esta actualización haremos tanto al enrutador de plato,
al enrutador promocional y al enrutador líder en nuestro lado del servidor.
La siguiente parte es, por supuesto, la autenticación del usuario.
Por lo tanto, como nos hemos dado cuenta en el lado del servidor,
ya tenemos estos puntos finales de API REST,
que son útiles para la autenticación del usuario.
En particular, cuando usted hace una publicación a /users/login,
con el nombre de usuario y la contraseña, entonces,
usted será capaz de autenticar al usuario en el lado del servidor.
Ahora, cuando el usuario se autentica correctamente en el lado del servidor,
el mensaje de respuesta proveniente del lado del servidor incluirá
el token web JSON en el cuerpo de respuesta del mensaje de respuesta entrante desde el lado del servidor.
Por lo tanto, en el lado del cliente,
deberíamos poder extraer este token y luego usar este token posteriormente.
Por lo tanto, cuando el cliente recibe el mensaje de respuesta
del lado del servidor y el usuario se autentica correctamente en el lado del servidor,
el mensaje de respuesta contendrá el token web JSON,
que debe extraerse, y a partir de entonces,
el cliente debe incluir este token web JSON en
el para cada solicitud saliente desde el lado del cliente.
Entonces, ¿cómo manejamos todo este conjunto de operaciones?
Ahora, aquí es donde implementaremos
otro servicio que será utilizado en nuestro lado cliente,
en nuestro cliente Angular,
llamado el servicio de autenticación,
y ahí es donde manejaremos todas las operaciones de inicio de sesión y cierre de sesión.
Ahora, el proceso de cierre de sesión es bastante sencillo pero,
si destruimos el token web JSON que tenemos en el lado
del cliente, entonces el cliente ya no podrá acceder al servidor.
Por lo tanto, es tan simple como simplemente destruir
el token web JSON en el lado del cliente para cerrar sesión en ese cliente.
Por lo tanto, teniendo en cuenta esta comprensión,
veamos los pasos que están involucrados en
hacer la autenticación del usuario y manejar la autenticación del usuario en el lado del cliente.
Por lo tanto, para manejar la autenticación del usuario en el lado
del cliente, el cliente enviará una solicitud de publicación al endpoint /users/login,
y el cuerpo de la solicitud de publicación contendrá el nombre de usuario y la contraseña.
Estamos utilizando la autenticación de inicio de sesión en este caso.
Ahora, para la autenticación de Facebook de nuevo,
esa es una configuración diferente que no voy a discutir en este momento.
Pero, el cuerpo de la solicitud como verá para la autenticación local,
contendrá el nombre de usuario y la contraseña.
Por lo tanto, cuando el usuario se autentica correctamente en el lado
del servidor, el servidor responderá de nuevo
al cliente incluyendo el token web JSON en el mensaje de respuesta.
Por lo tanto, cuando el cliente recibe el mensaje de respuesta desde el lado del servidor,
entonces el cliente tendrá que capturar este token web JSON
y luego guardar el token web JSON en el almacenamiento local en el lado del cliente.
A partir de entonces, el cliente debe incluir este token en cada solicitud saliente.
Entonces, ¿cómo se logra esto en el lado del cliente?
En primer lugar, por supuesto,
debe guardar el token web JSON entrante en el almacenamiento local,
y eso se hace en el servicio de autenticación que implementaremos en el lado del cliente.
Ahora, para cada solicitud saliente,
el cliente incluirá este token en el encabezado,
el encabezado de autorización de la solicitud saliente.
Ahora, ¿cómo se logra esto?
Entonces, aquí es donde vamos a tomar la ayuda de un interceptor HTTP,
que el HttpClient en Angular soporta.
Por lo tanto, con el interceptor HTTP,
el interceptor nos permite interceptar
cada mensaje de solicitud saliente o incluso
interceptar cada mensaje de respuesta entrante si así lo desea.
Pero en la aplicación Angular,
vamos a implementar el interceptor de solicitudes,
que ilustraré en el ejercicio más adelante.
En el interceptor de solicitudes HTTP,
cuando se intercepta el mensaje de solicitud,
cada mensaje de solicitud saliente será interceptado y luego el token web JSON
se insertará en el encabezado de autorización del mensaje de solicitud.
Luego, a partir de entonces, el mensaje de solicitud se transmitiría al lado del servidor. Por
lo tanto, cada solicitud saliente después de que el usuario se autentica en el lado del servidor,
cada solicitud saliente del lado del cliente llevará
el token web JSON en el encabezado de autorización de la solicitud saliente.
Ahora, una vez que el cliente cierra la sesión,
el token web JSON se destruirá en el lado del cliente.
Por lo tanto, a partir de entonces, las solicitudes salientes ya no contendrán el token web
JSON, porque el token web JSON no existe en el lado del cliente.
Por lo tanto, el usuario pierde la autenticación.
Entonces, así es como manejaremos el proceso de inicio de sesión y cierre de sesión en el lado del cliente,
comunicándonos con el servidor,
y luego obtendremos el token web JSON,
y luego incluiremos el token web JSON en cada solicitud saliente.
Ahora, con esta comprensión de cómo interactuarán el cliente y el servidor,
procedamos ahora a los siguientes dos ejercicios.
Primero, actualizaremos el lado del servidor con algunas adiciones,
para que pueda integrarse bien con nuestro sitio cliente.
A partir de entonces, actualizaremos el lado del cliente o más bien le daré
una aplicación cliente completa que he
tomado del curso Angular anterior y luego la actualizaré, lo
que también nos proporciona la capacidad de usar interceptores HTTP
tanto en las solicitudes salientes como en el mensajes de respuesta entrantes.
Por lo tanto, trataremos ambos en los próximos dos ejercicios,
y al final, comprenderá cómo
integrar su cliente y el lado del servidor.