En este módulo, en la primera lección,
aprendimos cómo construir un servidor API REST completo usando express.
Por lo tanto, podemos atender las
solicitudes GET, PUT, POST y DELETE que llegan a los diversos puntos finales de la API REST.
Pero, el servidor en sí simplemente estaba devolviendo
un mensaje simple en respuesta a estas solicitudes.
En un servidor API REST real,
cualquier solicitud entrante implicará una operación correspondiente que se realizará en la parte posterior de
la base de datos tal vez para recuperar datos para responder a una solicitud GET,
o tal vez para modificar los datos que existen en el servidor en respuesta a una solicitud PUT.
Ahora en el resto de este módulo,
hemos estudiado cómo podemos interactuar desde una aplicación de nodo con un servidor MongoDB,
ya sea usando el controlador MongoDB o usando Mongoose.
Ahora, un servidor API REST completo que sea capaz de manejar
la solicitud de extremo a extremo solo será posible cuando combinemos los dos juntos.
Es decir, un servidor basado en expreso que realiza
todo el procesamiento de lógica empresarial y al mismo tiempo emitirá
las solicitudes de base de datos al MongoDB
usando el controlador de nodo MongoDB o usando Mongoose.
Entonces, ¿cómo combinamos los dos juntos?
Así que esto es lo que veremos en esta lección en particular,
y los dos ejercicios que haremos como parte de esta lección.
Ahora hemos aprendido cómo construir
un servidor de API REST usando Express
y dar servicio a las diversas solicitudes que llegan a los extremos de la API REST.
También hemos visto cómo podemos interactuar con la base de datos desde nuestra aplicación de nodos.
Ahora, dado que tiene una solicitud GET entrando en el servidor como ejemplo,
para manejar esta solicitud GET de extremo a extremo,
una solicitud GET procedente del cliente significa que el cliente desea recuperar
datos del servidor y usar esos datos.
Por lo tanto, una solicitud GET que entra en el servidor tendrá que ser
manejada a través de los diversos procesos realizados por, por ejemplo,
el servidor Express y una vez que se realiza el procesamiento, la
lógica empresarial del servidor Express se da cuenta de que necesita
realizar una operación de consulta en la base de datos.
Por lo tanto, esto puede iniciar una consulta a la base de datos con el fin de
obtener un conjunto de documentos de la base de datos,
y luego los datos recuperados se
transformarán en un mensaje de respuesta y luego se enviarán de vuelta al servidor.
Por lo tanto, este manejo de extremo a extremo de la solicitud y la respuesta involucra dos partes.
Uno, por supuesto, está haciendo la lógica de negocio en
el servidor Express y luego haciendo la interacción con
la base de datos desde la aplicación de nodo del servidor Express que es
una aplicación de nodo que usa el controlador MongoDB o Mangoose.
Vamos a usar Mangosta en los ejercicios.
Del mismo modo, una solicitud POST que llega
al punto final de la API REST
en el servidor significa que la solicitud POST trae algunos datos en el cuerpo del mensaje.
Por lo tanto, esta información debe procesarse en el servidor Express
y la información que debe almacenarse en
la base de datos debe recuperarse del cuerpo de la solicitud POST entrante y luego la
solicitud de creación correspondiente debe
crearse o iniciarse desde el servidor Express a la base de datos MongoDB,
y en la solicitud de creación,
la información que se ha recuperado del cuerpo de
la solicitud POST será enviada a
la base de datos para crear un nuevo documento en una colección específica en la base de datos.
Y luego el resultado de esta operación se enviará de
vuelta al cliente en el mensaje de respuesta.
Por lo tanto, cualquier operación que se realice en un punto final de API REST, ya sea una operación GET,
un PUT, un POST
o una operación DELETE,
como puede ver en estos dos ejemplos,
iniciará una operación de base de datos correspondiente detrás de escena.
Entonces, habiendo entendido esta interacción,
lo que nos damos cuenta es que una solicitud HTTP que llega a
un punto final de API REST tiene que ser mapeada en una operación de base de datos correspondiente.
Por lo tanto, cada solicitud entrante, GET, PUT, POST
o DELETE significa que se puede acceder a un recurso específico en la base de datos,
puede ser recuperado o un grupo de recursos puede ser
recuperado de la base de datos y luego enviado de vuelta al servidor,
o un recurso puede ser modificado en respuesta a un PUT o un POST
o incluso una solicitud DELETE que llega al servidor REST API.
Por lo tanto, depende de la lógica del servidor Express,
la lógica empresarial implementada en el servidor Express REST API,
manejar esta traducción de la solicitud entrante, ya sea una solicitud GET,
PUT, POST o DELETE en la operación de base de datos correspondiente.
Así que veamos un ejemplo de esto con un poco más de detalle.
Por lo tanto, llegando a la combinación del router Express más
MongoDB más Mangoose que actúa como el ODM en el medio,
las operaciones a realizar de la base de datos tienen que iniciarse
dentro del router que construimos para cada uno de los extremos de la API REST.
Entonces, dentro del enrutador,
incluso el método GET,
el método PUT o el método POST.
La acción correspondiente a realizar en la base de datos si se trata de una solicitud GET
provocando la ejecución de un método de búsqueda de
platos o de una solicitud POST provocando la ejecución de un método de creación de platos,
tendrá que ser realizada por nuestro servidor Express dando como resultado
la operación correspondiente iniciado en la base de datos MongoDB.
Entonces, con esta comprensión de
cómo las solicitudes se traducen en una operación de base de datos correspondiente,
vamos a continuar con los dos ejercicios donde veremos manejar la
solicitud GET, PUT, POST y DELETE llegando a los puntos finales /dishes/:DISHID y
también para modificar comentarios que se encuentran en
los sub-documentos adjuntos dentro del documento del plato.