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 en los cursos anteriores,
cómo integramos las dos juntas para que nuestra puede
interactuar con el servidor API REST completo que hemos desarrollado en este curso?
Por lo tanto, esto es lo que examinaremos en
esta conferencia y los dos ejercicios que siguen a esta conferencia.
Por lo tanto, al final de esta lección,
tendrá React Client que será
capaz de comunicarse con el servidor que acaba de desarrollar en
este curso y ser capaz de soportar
la vista completa del lado del cliente de toda nuestra aplicación.
Así veremos que hemos desarrollado
la
aplicación completa de extremo a extremo desde el lado del cliente hasta el lado del servidor en este curso.
Para integrar el cliente y el servidor,
como nos hemos dado cuenta de que nuestro servidor ya está
implementado para soportar 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.
A continuación, el cliente puede hacer uso de los datos JSON para representar 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.
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 luego 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 pequeños ajustes 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 destacada,
vimos que la URL incluye, la
característica de signo de interrogación de platos es igual a
verdadero 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 la bandera destacada 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.
Por lo tanto, para hacer eso como vimos,
la URL que se utiliza para enviar la solicitud al servidor es,
slash platos signo de interrogación presentado es igual a true.
Por lo tanto, así es como proporcionaremos los parámetros de consulta a nuestro lado del servidor.
Ahora, además, cuando se recibe esta información en el lado del servidor,
ahora vimos que antes cuando hicimos la solicitud get en el lado del servidor,
simplemente dijimos que los platos encuentran y luego encontraríamos
todos los platos y luego devolverlos cuando
se envía la solicitud get a la ruta del enrutador plato barra .
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 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, cualquier parámetro de consulta que incluya en la URL se convertirá en
objetos JSON correspondientes con la información establecida como
se muestra aquí y luego se cargará 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í.
Por lo tanto, cuando se
consulta el MongoDB, 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, Autenticación de 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 de usuario,
en particular cuando haces una publicación para reducir los usuarios
el inicio de sesión con el nombre de usuario y
la contraseña, entonces podrás autenticar al usuario en el servidor lado.
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 desde
el 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.
Esto se logra guardando el token web JSON en el almacenamiento local.
A partir de entonces, para cada solicitud de búsqueda que emita,
podemos configurar el encabezado de autorización para contener el token web JSON.
Ahora, el proceso de cierre de sesión es bastante sencillo,
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 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 en el manejo de 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 extremo de inicio de sesión de los usuarios de barra diagonal,
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 tal como ve 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 JSON Web Token y luego
guardar el JSON Web Token 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, necesitamos guardar el token web JSON en el almacenamiento local.
Ahora, esto se logra dentro del creador de acciones que maneja el proceso de inicio de sesión del usuario.
Por lo tanto, cuando la publicación se realiza en el servidor desde el creador de inducción del lado del cliente
, el mensaje de respuesta contendrá el token,
y este token se guarda en el creador de acción que maneja el proceso de inicio de sesión del usuario.
Ahora a partir de entonces, cuando se realiza cualquier solicitud de recuperación,
entonces podemos establecer fácilmente el encabezado de autorización en la solicitud de recuperación saliente.
Ahora, una vez que el cliente cierra la sesión,
el token web JSON se destruirá en el lado del cliente.
Entonces, 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.
Por lo tanto, así es como manejaremos el proceso de inicio de sesión y cierre de sesión en el lado del cliente.
Al comunicarse con el servidor y luego obtener el token web JSON y
luego incluir 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 lado cliente.
A partir de entonces, actualizaremos el lado del cliente o más bien le daré
una aplicación cliente completa que he tomado
de la fuerza de reacción anterior y la adapté, la actualizé.
Por lo tanto, trataremos ambos en los próximos dos ejercicios,
y al final de esto comprenderá cómo integrar su lado cliente y servidor.