1
00:00:03,940 --> 00:00:08,444
En este módulo, en la primera lección,

2
00:00:08,444 --> 00:00:14,115
aprendimos cómo construir un servidor API REST completo usando express.

3
00:00:14,115 --> 00:00:17,120
Por lo tanto, podemos atender las

4
00:00:17,120 --> 00:00:22,185
solicitudes GET, PUT, POST y DELETE que llegan a los diversos puntos finales de la API REST.

5
00:00:22,185 --> 00:00:24,975
Pero, el servidor en sí simplemente estaba devolviendo

6
00:00:24,975 --> 00:00:29,115
un mensaje simple en respuesta a estas solicitudes.

7
00:00:29,115 --> 00:00:32,778
En un servidor API REST real,

8
00:00:32,778 --> 00:00:39,620
cualquier solicitud entrante implicará una operación correspondiente que se realizará en la parte posterior de

9
00:00:39,620 --> 00:00:46,610
la base de datos tal vez para recuperar datos para responder a una solicitud GET,

10
00:00:46,610 --> 00:00:52,430
o tal vez para modificar los datos que existen en el servidor en respuesta a una solicitud PUT.

11
00:00:52,430 --> 00:00:56,270
Ahora en el resto de este módulo,

12
00:00:56,270 --> 00:01:03,465
hemos estudiado cómo podemos interactuar desde una aplicación de nodo con un servidor MongoDB,

13
00:01:03,465 --> 00:01:10,500
ya sea usando el controlador MongoDB o usando Mongoose.

14
00:01:10,500 --> 00:01:15,600
Ahora, un servidor API REST completo que sea capaz de manejar

15
00:01:15,600 --> 00:01:21,468
la solicitud de extremo a extremo solo será posible cuando combinemos los dos juntos.

16
00:01:21,468 --> 00:01:24,840
Es decir, un servidor basado en expreso que realiza

17
00:01:24,840 --> 00:01:29,340
todo el procesamiento de lógica empresarial y al mismo tiempo emitirá

18
00:01:29,340 --> 00:01:34,200
las solicitudes de base de datos al MongoDB

19
00:01:34,200 --> 00:01:40,790
usando el controlador de nodo MongoDB o usando Mongoose.

20
00:01:40,790 --> 00:01:42,780
Entonces, ¿cómo combinamos los dos juntos?

21
00:01:42,780 --> 00:01:47,040
Así que esto es lo que veremos en esta lección en particular,

22
00:01:47,040 --> 00:01:51,230
y los dos ejercicios que haremos como parte de esta lección.

23
00:01:51,230 --> 00:01:55,875
Ahora hemos aprendido cómo construir

24
00:01:55,875 --> 00:01:59,400
un servidor de API REST usando Express

25
00:01:59,400 --> 00:02:03,950
y dar servicio a las diversas solicitudes que llegan a los extremos de la API REST.

26
00:02:03,950 --> 00:02:10,765
También hemos visto cómo podemos interactuar con la base de datos desde nuestra aplicación de nodos.

27
00:02:10,765 --> 00:02:17,280
Ahora, dado que tiene una solicitud GET entrando en el servidor como ejemplo,

28
00:02:17,280 --> 00:02:20,550
para manejar esta solicitud GET de extremo a extremo,

29
00:02:20,550 --> 00:02:25,500
una solicitud GET procedente del cliente significa que el cliente desea recuperar

30
00:02:25,500 --> 00:02:31,830
datos del servidor y usar esos datos.

31
00:02:31,830 --> 00:02:34,590
Por lo tanto, una solicitud GET que entra en el servidor tendrá que ser

32
00:02:34,590 --> 00:02:39,060
manejada a través de los diversos procesos realizados por, por ejemplo,

33
00:02:39,060 --> 00:02:43,880
el servidor Express y una vez que se realiza el procesamiento, la

34
00:02:43,880 --> 00:02:47,340
lógica empresarial del servidor Express se da cuenta de que necesita

35
00:02:47,340 --> 00:02:51,166
realizar una operación de consulta en la base de datos.

36
00:02:51,166 --> 00:02:54,630
Por lo tanto, esto puede iniciar una consulta a la base de datos con el fin de

37
00:02:54,630 --> 00:02:58,605
obtener un conjunto de documentos de la base de datos,

38
00:02:58,605 --> 00:03:02,850
y luego los datos recuperados se

39
00:03:02,850 --> 00:03:07,650
transformarán en un mensaje de respuesta y luego se enviarán de vuelta al servidor.

40
00:03:07,650 --> 00:03:15,340
Por lo tanto, este manejo de extremo a extremo de la solicitud y la respuesta involucra dos partes.

41
00:03:15,340 --> 00:03:18,060
Uno, por supuesto, está haciendo la lógica de negocio en

42
00:03:18,060 --> 00:03:23,070
el servidor Express y luego haciendo la interacción con

43
00:03:23,070 --> 00:03:27,270
la base de datos desde la aplicación de nodo del servidor Express que es

44
00:03:27,270 --> 00:03:32,580
una aplicación de nodo que usa el controlador MongoDB o Mangoose.

45
00:03:32,580 --> 00:03:36,190
Vamos a usar Mangosta en los ejercicios.

46
00:03:36,190 --> 00:03:42,005
Del mismo modo, una solicitud POST que llega

47
00:03:42,005 --> 00:03:46,420
al punto final de la API REST

48
00:03:46,420 --> 00:03:51,330
en el servidor significa que la solicitud POST trae algunos datos en el cuerpo del mensaje.

49
00:03:51,330 --> 00:03:55,795
Por lo tanto, esta información debe procesarse en el servidor Express

50
00:03:55,795 --> 00:04:01,150
y la información que debe almacenarse en

51
00:04:01,150 --> 00:04:07,208
la base de datos debe recuperarse del cuerpo de la solicitud POST entrante y luego la

52
00:04:07,208 --> 00:04:11,380
solicitud de creación correspondiente debe

53
00:04:11,380 --> 00:04:17,590
crearse o iniciarse desde el servidor Express a la base de datos MongoDB,

54
00:04:17,590 --> 00:04:19,450
y en la solicitud de creación,

55
00:04:19,450 --> 00:04:22,330
la información que se ha recuperado del cuerpo de

56
00:04:22,330 --> 00:04:25,870
la solicitud POST será enviada a

57
00:04:25,870 --> 00:04:33,130
la base de datos para crear un nuevo documento en una colección específica en la base de datos.

58
00:04:33,130 --> 00:04:36,550
Y luego el resultado de esta operación se enviará de

59
00:04:36,550 --> 00:04:40,200
vuelta al cliente en el mensaje de respuesta.

60
00:04:40,200 --> 00:04:45,640
Por lo tanto, cualquier operación que se realice en un punto final de API REST, ya sea una operación GET,

61
00:04:45,640 --> 00:04:47,155
un PUT, un POST

62
00:04:47,155 --> 00:04:48,951
o una operación DELETE,

63
00:04:48,951 --> 00:04:51,005
como puede ver en estos dos ejemplos,

64
00:04:51,005 --> 00:04:58,063
iniciará una operación de base de datos correspondiente detrás de escena.

65
00:04:58,063 --> 00:05:01,120
Entonces, habiendo entendido esta interacción,

66
00:05:01,120 --> 00:05:05,590
lo que nos damos cuenta es que una solicitud HTTP que llega a

67
00:05:05,590 --> 00:05:10,360
un punto final de API REST tiene que ser mapeada en una operación de base de datos correspondiente.

68
00:05:10,360 --> 00:05:12,260
Por lo tanto, cada solicitud entrante, GET, PUT, POST

69
00:05:12,260 --> 00:05:19,270
o DELETE significa que se puede acceder a un recurso específico en la base de datos,

70
00:05:19,270 --> 00:05:23,530
puede ser recuperado o un grupo de recursos puede ser

71
00:05:23,530 --> 00:05:28,360
recuperado de la base de datos y luego enviado de vuelta al servidor,

72
00:05:28,360 --> 00:05:34,015
o un recurso puede ser modificado en respuesta a un PUT o un POST

73
00:05:34,015 --> 00:05:40,425
o incluso una solicitud DELETE que llega al servidor REST API.

74
00:05:40,425 --> 00:05:44,170
Por lo tanto, depende de la lógica del servidor Express,

75
00:05:44,170 --> 00:05:47,545
la lógica empresarial implementada en el servidor Express REST API,

76
00:05:47,545 --> 00:05:53,860
manejar esta traducción de la solicitud entrante, ya sea una solicitud GET,

77
00:05:53,860 --> 00:05:58,765
PUT, POST o DELETE en la operación de base de datos correspondiente.

78
00:05:58,765 --> 00:06:03,085
Así que veamos un ejemplo de esto con un poco más de detalle.

79
00:06:03,085 --> 00:06:07,480
Por lo tanto, llegando a la combinación del router Express más

80
00:06:07,480 --> 00:06:12,445
MongoDB más Mangoose que actúa como el ODM en el medio,

81
00:06:12,445 --> 00:06:17,710
las operaciones a realizar de la base de datos tienen que iniciarse

82
00:06:17,710 --> 00:06:23,275
dentro del router que construimos para cada uno de los extremos de la API REST.

83
00:06:23,275 --> 00:06:24,310
Entonces, dentro del enrutador,

84
00:06:24,310 --> 00:06:26,740
incluso el método GET,

85
00:06:26,740 --> 00:06:28,615
el método PUT o el método POST.

86
00:06:28,615 --> 00:06:35,440
La acción correspondiente a realizar en la base de datos si se trata de una solicitud GET

87
00:06:35,440 --> 00:06:39,940
provocando la ejecución de un método de búsqueda de

88
00:06:39,940 --> 00:06:44,235
platos o de una solicitud POST provocando la ejecución de un método de creación de platos,

89
00:06:44,235 --> 00:06:48,595
tendrá que ser realizada por nuestro servidor Express dando como resultado

90
00:06:48,595 --> 00:06:53,285
la operación correspondiente iniciado en la base de datos MongoDB.

91
00:06:53,285 --> 00:06:55,555
Entonces, con esta comprensión de

92
00:06:55,555 --> 00:07:00,655
cómo las solicitudes se traducen en una operación de base de datos correspondiente,

93
00:07:00,655 --> 00:07:06,720
vamos a continuar con los dos ejercicios donde veremos manejar la

94
00:07:06,720 --> 00:07:15,040
solicitud GET, PUT, POST y DELETE llegando a los puntos finales /dishes/:DISHID y

95
00:07:15,040 --> 00:07:18,940
también para modificar comentarios que se encuentran en

96
00:07:18,940 --> 00:07:24,470
los sub-documentos adjuntos dentro del documento del plato.