1
00:00:03,810 --> 00:00:05,895
En la conferencia anterior,

2
00:00:05,895 --> 00:00:07,880
aprendimos acerca de la API REST.

3
00:00:07,880 --> 00:00:10,781
Ha visto cómo los extremos de la API REST

4
00:00:10,781 --> 00:00:14,990
admiten una forma de que una aplicación cliente pueda recuperar

5
00:00:14,990 --> 00:00:23,100
datos del servidor o cargar datos en el servidor mediante las diversas operaciones HTTP.

6
00:00:23,100 --> 00:00:27,062
En esta conferencia y ejercicio que sigue a esta conferencia,

7
00:00:27,062 --> 00:00:30,985
veremos específicamente qué tipo de soporte

8
00:00:30,985 --> 00:00:36,545
admite Express para diseñar e implementar un servidor basado en API REST.

9
00:00:36,545 --> 00:00:40,085
En particular, también veremos el router Express,

10
00:00:40,085 --> 00:00:44,600
y cómo nos permite subdividir nuestra aplicación y

11
00:00:44,600 --> 00:00:50,285
luego organizarla en múltiples aplicaciones tipo mini Express,

12
00:00:50,285 --> 00:00:54,495
que se combinan para formar la aplicación Express,

13
00:00:54,495 --> 00:01:00,605
específicamente cuando estamos tratando con varias API REST y partes.

14
00:01:00,605 --> 00:01:02,985
Así que para resumir, en la conferencia anterior,

15
00:01:02,985 --> 00:01:06,315
examinamos REST en detalle.

16
00:01:06,315 --> 00:01:10,560
También analizamos cómo cada extremo es identificado por un URI,

17
00:01:10,560 --> 00:01:13,950
y cómo podemos especificar las diversas operaciones que se deben realizar en

18
00:01:13,950 --> 00:01:18,295
cada extremo utilizando el verbo HTTP apropiado,

19
00:01:18,295 --> 00:01:20,880
GET, PUT, POST o DELETE.

20
00:01:20,880 --> 00:01:22,560
Ahora, en esta conferencia,

21
00:01:22,560 --> 00:01:29,530
veremos cómo Express soporta el desarrollo de un servidor de API REST.

22
00:01:29,530 --> 00:01:35,070
Vamos a ver el soporte de Express para varios asuntos como app.all,

23
00:01:35,070 --> 00:01:38,335
app.get, put, post y delete,

24
00:01:38,335 --> 00:01:43,305
y cómo estos métodos se pueden usar para construir un servidor API REST.

25
00:01:43,305 --> 00:01:50,104
Dentro de Express, los distintos grupos de aplicaciones se pueden definir mediante la aplicación,.

26
00:01:50,104 --> 00:01:51,955
y los diversos métodos.

27
00:01:51,955 --> 00:01:59,180
Por lo tanto, la app.all especifica una operación que debe hacerse en todos los diversos verbos,

28
00:01:59,180 --> 00:02:00,990
on, in, and part.

29
00:02:00,990 --> 00:02:04,050
Así, por ejemplo, en este ejemplo,

30
00:02:04,050 --> 00:02:07,970
vemos que el endpoint está definido por /dish,

31
00:02:07,970 --> 00:02:13,230
y por lo tanto la app.all, lo que se especifique en la función que se da para app.all,

32
00:02:13,230 --> 00:02:16,830
se aplicará a todas las solicitudes entrantes.

33
00:02:16,830 --> 00:02:22,155
App.get especifica lo que hay que hacer para las solicitudes GET y, en

34
00:02:22,155 --> 00:02:24,233
consecuencia, para las

35
00:02:24,233 --> 00:02:30,015
solicitudes POST, PUT y DELETE que se envían al extremo /dish,

36
00:02:30,015 --> 00:02:32,700
como se muestra en este ejemplo.

37
00:02:32,700 --> 00:02:39,471
Express también admite la definición de los endpoints con parámetros.

38
00:02:39,471 --> 00:02:45,750
Así, por ejemplo, puede especificar un ID de plato específico si lo desea,

39
00:02:45,750 --> 00:02:49,500
y luego dejar que la operación se realice para

40
00:02:49,500 --> 00:02:55,320
ese punto final específico refiriéndose a ese plato específico con un ID de plato dado.

41
00:02:55,320 --> 00:02:58,890
Entonces, en este caso, el ID de plato se

42
00:02:58,890 --> 00:03:03,706
especifica como parámetro y el patrón utilizado para eso es,

43
00:03:03,706 --> 00:03:05,460
como puede ver en este ejemplo,

44
00:03:05,460 --> 00:03:11,920
/dishes/: y luego especificaría el parámetro aquí.

45
00:03:11,920 --> 00:03:14,310
Para que nos sea fácil de entender,

46
00:03:14,310 --> 00:03:18,060
nombré el parámetro como DISHID allí.

47
00:03:18,060 --> 00:03:22,035
Puede usar cualquier nombre de parámetro que elija, pero de nuevo,

48
00:03:22,035 --> 00:03:27,290
usar un nombre significativo para un parámetro hace que sea más fácil entender el código.

49
00:03:27,290 --> 00:03:28,815
Así que en este ejemplo,

50
00:03:28,815 --> 00:03:34,058
The:DISHID significa que si emitimos una solicitud a un punto final,

51
00:03:34,058 --> 00:03:38,400
digamos por ejemplo, /dishes/23,

52
00:03:38,400 --> 00:03:45,300
entonces el parámetro DIShiD nos permite extraer este número 23 para que

53
00:03:45,300 --> 00:03:48,420
podamos operar en el plato número 23 dentro de

54
00:03:48,420 --> 00:03:52,496
la función que se especifica dentro de este método aquí.

55
00:03:52,496 --> 00:03:55,190
Entonces, allí, el parámetro,

56
00:03:55,190 --> 00:04:01,440
el parámetro DISHID en sí se puede obtener utilizando el objeto request en el que

57
00:04:01,440 --> 00:04:04,020
la propiedad params admitió y

58
00:04:04,020 --> 00:04:08,885
la propiedad params admite todos los parámetros de solicitud entrante,

59
00:04:08,885 --> 00:04:10,470
y DISHID, en particular,

60
00:04:10,470 --> 00:04:13,710
es uno de esos parámetros de solicitud que ,

61
00:04:13,710 --> 00:04:16,271
como se muestra en el código aquí.

62
00:04:16,271 --> 00:04:22,585
Cuando envía una solicitud PUT o POST desde el cliente al servidor,

63
00:04:22,585 --> 00:04:28,545
suele incluir los datos en el cuerpo del mensaje que se envía al servidor.

64
00:04:28,545 --> 00:04:31,110
Ahora, lo que significa que necesitamos un método para

65
00:04:31,110 --> 00:04:34,230
extraer información del cuerpo del mensaje.

66
00:04:34,230 --> 00:04:39,320
Entonces, aquí es donde el middleware del analizador corporal para Express es muy útil.

67
00:04:39,320 --> 00:04:44,805
Por lo tanto, el analizador del cuerpo nos permite analizar la información del cuerpo del mensaje.

68
00:04:44,805 --> 00:04:47,515
Para usar el analizador corporal, como era de esperar,

69
00:04:47,515 --> 00:04:52,155
instalaríamos el módulo de nodo body-parser,

70
00:04:52,155 --> 00:04:56,070
y luego lo necesitaríamos dentro de nuestra aplicación Express,

71
00:04:56,070 --> 00:04:59,550
y luego especificamos app.use (BodyParser).

72
00:04:59,550 --> 00:05:03,570
Y si el cuerpo contiene datos en el formato JSON,

73
00:05:03,570 --> 00:05:05,810
puede decir BodyParser.json,

74
00:05:05,810 --> 00:05:09,561
lo que significa que esto solo analizará los datos que están en

75
00:05:09,561 --> 00:05:14,250
formato JSON que está encerrado en el cuerpo de ese mensaje de solicitud.

76
00:05:14,250 --> 00:05:16,145
En particular, en el ejercicio,

77
00:05:16,145 --> 00:05:22,620
vamos a analizar los datos entrantes que se envían en forma de una cadena JSON.

78
00:05:22,620 --> 00:05:24,930
El analizador de cuerpo, como era de esperar,

79
00:05:24,930 --> 00:05:30,480
analiza el cuerpo del mensaje y rellena la propiedad req.body.

80
00:05:30,480 --> 00:05:32,190
Por lo tanto, en la solicitud,

81
00:05:32,190 --> 00:05:36,250
la propiedad body contendrá lo que se analiza desde

82
00:05:36,250 --> 00:05:41,600
el cuerpo del mensaje de solicitud por el analizador de cuerpo.

83
00:05:41,600 --> 00:05:45,030
Si está implementando una aplicación Express

84
00:05:45,030 --> 00:05:48,465
que admite múltiples puntos finales de API REST,

85
00:05:48,465 --> 00:05:53,265
entonces tiene sentido subdividir el código en

86
00:05:53,265 --> 00:05:59,520
varios módulos y luego hacer uso de ellos para construir la aplicación Express general.

87
00:05:59,520 --> 00:06:03,347
Entonces aquí donde el enrutador Express viene en nuestra ayuda.

88
00:06:03,347 --> 00:06:08,070
Un router Express define muchas aplicaciones Express,

89
00:06:08,070 --> 00:06:10,045
y dentro de esas muchas aplicaciones Express,

90
00:06:10,045 --> 00:06:11,480
puede, por ejemplo,

91
00:06:11,480 --> 00:06:16,550
tratar con un punto final de API REST en particular con más detalle,

92
00:06:16,550 --> 00:06:20,215
o un patrón particular de extremo API REST con más detalle.

93
00:06:20,215 --> 00:06:27,656
Entonces, por ejemplo, podemos definir un DishRouter como express.Router,

94
00:06:27,656 --> 00:06:32,450
y luego el DishRouter puede manejar los puntos finales.

95
00:06:32,450 --> 00:06:35,420
Así que cuando expresas algo como express.Router,

96
00:06:35,420 --> 00:06:38,570
es compatible con el punto final de la ruta.

97
00:06:38,570 --> 00:06:41,015
Una de las razones para usar el router Express,

98
00:06:41,015 --> 00:06:42,455
como se daría cuenta,

99
00:06:42,455 --> 00:06:45,470
es que si usamos los

100
00:06:45,470 --> 00:06:47,142
métodos GET, PUT, POST y DELETE de la aplicación estándar,

101
00:06:47,142 --> 00:06:48,760
para cada uno de estos métodos, es

102
00:06:48,760 --> 00:06:52,315
necesario especificar explícitamente los extremos de la API REST.

103
00:06:52,315 --> 00:06:55,130
Una ventaja de usar el router Express es que si

104
00:06:55,130 --> 00:06:59,422
dice el router.Route y luego especifica el punto final,

105
00:06:59,422 --> 00:07:07,220
ese extremo se aplicará a todos los métodos y todos los diversos

106
00:07:07,220 --> 00:07:11,060
métodos relacionados con GET, PUT, POST y DELETE se pueden encadenar

107
00:07:11,060 --> 00:07:16,575
juntos en la ruta en la definición del código para nuestra aplicación.

108
00:07:16,575 --> 00:07:22,075
Vamos a ver más detalles de esto en el ejercicio que sigue a esta conferencia.

109
00:07:22,075 --> 00:07:27,505
Con esta rápida comprensión de cómo Express soporta endpoint API REST,

110
00:07:27,505 --> 00:07:31,070
pasemos al ejercicio en el que construiremos

111
00:07:31,070 --> 00:07:35,682
su soporte para el endpoint de la API REST.

112
00:07:35,682 --> 00:07:38,180
Como parte de la primera asignación,

113
00:07:38,180 --> 00:07:40,160
ampliará aún más

114
00:07:40,160 --> 00:07:44,559
esta aplicación Express para admitir puntos finales de API REST adicionales,

115
00:07:44,559 --> 00:07:48,990
incluyendo /promotions y /leaders.

116
00:07:48,990 --> 00:07:52,040
Si ha tomado los cursos anteriores en la especialización,

117
00:07:52,040 --> 00:07:55,220
inmediatamente comenzará a ver por qué estamos soportando

118
00:07:55,220 --> 00:08:00,810
todos estos diferentes extremos de la API REST en el otro lado del servidor.