1
00:00:01,670 --> 00:00:04,320
‫Instructor: Ahora que sabemos qué es Express,

2
00:00:04,320 --> 00:00:07,550
‫estamos casi listos para comenzar a construir nuestra API.

3
00:00:07,550 --> 00:00:08,890
‫Pero antes de

4
00:00:08,890 --> 00:00:12,300
‫hacer eso, necesito hablar rápidamente sobre las API en un

5
00:00:12,300 --> 00:00:13,910
‫nivel superior y, lo que

6
00:00:13,910 --> 00:00:16,370
‫es más importante, presentarles la Arquitectura REST,

7
00:00:16,370 --> 00:00:19,640
‫que es la arquitectura API más utilizada en la actualidad.

8
00:00:19,640 --> 00:00:23,270
‫De esta manera, realmente sabremos lo que estamos construyendo.

9
00:00:23,270 --> 00:00:25,710
‫Por lo tanto, es extremadamente importante comprender el

10
00:00:25,710 --> 00:00:27,860
‫contenido de este video antes de

11
00:00:27,860 --> 00:00:30,580
‫continuar, para que sepamos realmente lo que estamos construyendo

12
00:00:30,580 --> 00:00:32,603
‫durante el resto del curso.

13
00:00:33,630 --> 00:00:34,890
‫En primer

14
00:00:34,890 --> 00:00:38,390
‫lugar, API significa Interfaz de programación de aplicaciones y, en

15
00:00:38,390 --> 00:00:40,130
‫un nivel muy alto, es

16
00:00:40,130 --> 00:00:43,150
‫básicamente una pieza de software que puede ser utilizada

17
00:00:43,150 --> 00:00:45,270
‫por otra pieza de software para

18
00:00:45,270 --> 00:00:48,213
‫permitir que las aplicaciones se comuniquen entre sí.

19
00:00:49,080 --> 00:00:51,420
‫De hecho, hemos hablado antes de

20
00:00:51,420 --> 00:00:53,780
‫las API, más específicamente, de las API web,

21
00:00:53,780 --> 00:00:56,300
‫en las que simplemente creamos una aplicación que

22
00:00:56,300 --> 00:00:59,640
‫envía datos a un cliente cada vez que entra una solicitud.

23
00:00:59,640 --> 00:01:02,530
‫Imagina que tenemos nuestra aplicación ejecutándose en un servidor

24
00:01:02,530 --> 00:01:04,060
‫y tenemos un cliente.

25
00:01:04,060 --> 00:01:08,020
‫Entonces, de hecho, efectivamente tenemos dos piezas de software

26
00:01:08,020 --> 00:01:10,250
‫hablando entre sí, ¿verdad?

27
00:01:10,250 --> 00:01:13,550
‫Y este es el tipo de API que crearemos en este curso.

28
00:01:13,550 --> 00:01:17,470
‫Y supongo que es el tipo de API más utilizado que existe.

29
00:01:17,470 --> 00:01:21,970
‫Pero, de hecho, las API no solo se utilizan para enviar datos y

30
00:01:21,970 --> 00:01:25,493
‫no siempre están relacionadas con el desarrollo web o JavaScript.

31
00:01:26,400 --> 00:01:29,500
‫La aplicación en API en realidad puede

32
00:01:29,500 --> 00:01:32,710
‫significar muchas cosas diferentes siempre que el

33
00:01:32,710 --> 00:01:35,050
‫software sea relativamente independiente.

34
00:01:35,050 --> 00:01:35,900
‫Tomemos, por

35
00:01:35,900 --> 00:01:38,870
‫ejemplo, el sistema de archivos de nodo o los módulos HTTP.

36
00:01:38,870 --> 00:01:42,010
‫Podemos decir que son pequeñas piezas de

37
00:01:42,010 --> 00:01:43,110
‫software y

38
00:01:43,110 --> 00:01:46,970
‫podemos usarlas, podemos interactuar con ellas usando su API.

39
00:01:46,970 --> 00:01:47,803
‫Por

40
00:01:47,803 --> 00:01:51,150
‫ejemplo, cuando usamos la función readfile del módulo FS,

41
00:01:51,150 --> 00:01:54,020
‫en realidad estamos usando la API FS.

42
00:01:54,020 --> 00:01:57,380
‫Y es por eso que a veces escuchará el término API de nodo.

43
00:01:57,380 --> 00:02:01,090
‫Y eso generalmente se refiere simplemente a los módulos de nodo central

44
00:02:01,090 --> 00:02:02,920
‫con los que podemos interactuar.

45
00:02:02,920 --> 00:02:05,670
‫O cuando hacemos manipulación DOM en el navegador,

46
00:02:05,670 --> 00:02:08,650
‫no estamos realmente usando el lenguaje JavaScript en sí,

47
00:02:08,650 --> 00:02:12,440
‫sino la API DOM que el navegador nos expone, por lo que

48
00:02:12,440 --> 00:02:14,280
‫nos da acceso a ella.

49
00:02:14,280 --> 00:02:15,930
‫O incluso otro ejemplo, digamos

50
00:02:15,930 --> 00:02:19,080
‫que creamos una clase en cualquier lenguaje de programación

51
00:02:19,080 --> 00:02:21,940
‫como Java y luego le agregamos algunos métodos

52
00:02:21,940 --> 00:02:23,420
‫públicos o propiedades.

53
00:02:23,420 --> 00:02:26,860
‫Estos métodos serán la API de cada objeto creado

54
00:02:26,860 --> 00:02:29,450
‫a partir de esa clase porque estamos

55
00:02:29,450 --> 00:02:31,890
‫dando a otras piezas de software la

56
00:02:31,890 --> 00:02:35,420
‫posibilidad de interactuar con nuestra pieza inicial de software, los

57
00:02:35,420 --> 00:02:37,278
‫objetos, en este caso.

58
00:02:37,278 --> 00:02:40,810
‫Verá, API tiene en realidad un significado más amplio

59
00:02:40,810 --> 00:02:42,810
‫que simplemente crear API web.

60
00:02:42,810 --> 00:02:47,420
‫¿Bien? De todos modos, una API web es

61
00:02:47,420 --> 00:02:50,340
‫lo más importante para nosotros en el contexto de la nota.

62
00:02:50,340 --> 00:02:53,050
‫Echemos ahora un vistazo a la arquitectura REST

63
00:02:53,050 --> 00:02:54,203
‫para crear API.

64
00:02:55,820 --> 00:02:59,910
‫REST, que significa Representational States Transfer, es básicamente una forma

65
00:02:59,910 --> 00:03:03,930
‫de construir API web de una manera lógica, haciéndolas

66
00:03:03,930 --> 00:03:06,060
‫fáciles de consumir porque

67
00:03:06,060 --> 00:03:09,420
‫recuerde, creamos una API para nosotros o para

68
00:03:09,420 --> 00:03:12,023
‫que otros la consuman, ¿de acuerdo?

69
00:03:12,023 --> 00:03:15,640
‫Queremos que el proceso de utilizar la API sea lo más

70
00:03:15,640 --> 00:03:17,633
‫sencillo posible para el usuario.

71
00:03:18,490 --> 00:03:20,830
‫Ahora, para construir API RESTful,

72
00:03:20,830 --> 00:03:24,180
‫lo que significa API siguiendo la Arquitectura REST, solo

73
00:03:24,180 --> 00:03:26,660
‫necesitamos seguir un par de principios.

74
00:03:26,660 --> 00:03:31,240
‫Primero, necesitamos separar nuestra API en recursos lógicos.

75
00:03:31,240 --> 00:03:33,860
‫Luego, estos recursos deben exponerse, lo

76
00:03:33,860 --> 00:03:35,900
‫que significa que deben

77
00:03:35,900 --> 00:03:39,420
‫estar disponibles mediante URL estructuradas y basadas en recursos.

78
00:03:39,420 --> 00:03:41,460
‫Para realizar diferentes acciones

79
00:03:41,460 --> 00:03:44,677
‫en los datos, como leer, crear o eliminar

80
00:03:44,677 --> 00:03:49,677
‫datos, la API debe usar los métodos HTP correctos y no la URL.

81
00:03:50,270 --> 00:03:53,210
‫Ahora, los datos que realmente enviamos al cliente

82
00:03:53,210 --> 00:03:55,420
‫o que recibimos del cliente

83
00:03:55,420 --> 00:03:58,030
‫generalmente deben usar el formato de datos

84
00:03:58,030 --> 00:04:01,010
‫JSON, donde se le aplica algún estándar de formato.

85
00:04:01,010 --> 00:04:04,500
‫Finalmente, otro principio importante de las API

86
00:04:04,500 --> 00:04:07,560
‫REST es que deben ser apátridas.

87
00:04:07,560 --> 00:04:09,950
‫Así que esta es una descripción general muy amplia.

88
00:04:09,950 --> 00:04:12,030
‫Comencemos ahora a hablar sobre estos principios

89
00:04:12,030 --> 00:04:15,310
‫uno por uno, comenzando con los recursos y usando la API

90
00:04:15,310 --> 00:04:17,810
‫de Nators que vamos a construir en este

91
00:04:17,810 --> 00:04:19,803
‫curso como un ejemplo aquí.

92
00:04:20,960 --> 00:04:24,910
‫La abstracción clave de información en REST es un recurso

93
00:04:24,910 --> 00:04:27,450
‫y, por lo tanto, todos los

94
00:04:27,450 --> 00:04:32,040
‫datos que queremos compartir en la API deben dividirse en recursos lógicos.

95
00:04:32,040 --> 00:04:34,350
‫Ahora bien, ¿qué es realmente un recurso?

96
00:04:34,350 --> 00:04:36,380
‫Bueno, en el contexto

97
00:04:36,380 --> 00:04:39,520
‫de REST, es un objeto o una representación

98
00:04:39,520 --> 00:04:42,020
‫de algo que tiene algunos datos asociados.

99
00:04:42,020 --> 00:04:42,853
‫Por ejemplo,

100
00:04:42,853 --> 00:04:45,570
‫tours, o usuarios, o reseñas en el

101
00:04:45,570 --> 00:04:48,020
‫caso del ejemplo que estamos siguiendo.

102
00:04:48,020 --> 00:04:50,730
‫Entonces, básicamente, cualquier información que se pueda nombrar

103
00:04:50,730 --> 00:04:53,040
‫puede ser un recurso, ¿de acuerdo?

104
00:04:53,040 --> 00:04:56,050
‫Sin embargo, solo tiene que ser un nombre, no un verbo.

105
00:04:56,050 --> 00:04:57,690
‫Ahora, necesitamos exponer,

106
00:04:57,690 --> 00:04:59,480
‫lo que significa poner a

107
00:04:59,480 --> 00:05:02,520
‫disposición, los datos utilizando algunas URL estructuradas a las

108
00:05:02,520 --> 00:05:04,890
‫que el cliente puede enviar una solicitud.

109
00:05:04,890 --> 00:05:07,611
‫Por ejemplo, algo como esto.

110
00:05:07,611 --> 00:05:10,740
‫Esta dirección completa se llama URL

111
00:05:10,740 --> 00:05:14,323
‫y este / addNewTour se llama API Endpoint.

112
00:05:15,269 --> 00:05:17,840
‫Nuestra API tendrá muchos puntos finales diferentes al

113
00:05:17,840 --> 00:05:20,560
‫igual que estos puntos finales ficticios que tengo

114
00:05:20,560 --> 00:05:23,730
‫aquí, cada uno de los cuales enviará datos diferentes al

115
00:05:23,730 --> 00:05:26,150
‫cliente o también realizará diferentes acciones.

116
00:05:26,150 --> 00:05:28,440
‫Ahora, en realidad, hay algo

117
00:05:28,440 --> 00:05:31,750
‫muy mal con estos puntos finales aquí porque realmente

118
00:05:31,750 --> 00:05:34,827
‫no siguen la tercera regla que dice que

119
00:05:34,827 --> 00:05:39,110
‫solo debemos usar los métodos HTTP para realizar acciones en los datos.

120
00:05:39,110 --> 00:05:42,360
‫Por lo tanto, los puntos finales solo deben contener nuestros recursos

121
00:05:42,360 --> 00:05:45,070
‫y no las acciones que se pueden realizar

122
00:05:45,070 --> 00:05:48,313
‫en ellos porque rápidamente se convertirán en una pesadilla de mantener.

123
00:05:49,644 --> 00:05:54,210
‫¿Cómo deberíamos utilizar estos métodos HTTP en la práctica?

124
00:05:54,210 --> 00:05:56,120
‫Bueno, veamos cómo deberían

125
00:05:56,120 --> 00:05:59,620
‫verse realmente estos puntos finales al comenzar con / getTour.

126
00:05:59,620 --> 00:06:03,290
‫Entonces, este punto final / getTour es para obtener datos sobre un recorrido.

127
00:06:03,290 --> 00:06:06,240
‫Entonces, simplemente deberíamos nombrar el punto final / recorridos y enviar

128
00:06:06,240 --> 00:06:08,740
‫los datos cada vez que se realiza una solicitud

129
00:06:08,740 --> 00:06:10,430
‫de obtención a este punto final.

130
00:06:10,430 --> 00:06:11,650
‫En otras palabras,

131
00:06:11,650 --> 00:06:14,730
‫cuando un cliente usa un método GET HTTP

132
00:06:14,730 --> 00:06:16,700
‫para acceder al punto final.

133
00:06:16,700 --> 00:06:17,870
‫Y así,

134
00:06:17,870 --> 00:06:20,220
‫solo tenemos recursos en el punto

135
00:06:20,220 --> 00:06:23,670
‫final o en la URL y no verbos porque

136
00:06:23,670 --> 00:06:26,870
‫el verbo ahora está en el método HTTP, ¿verdad?

137
00:06:26,870 --> 00:06:27,703
‫Y, por

138
00:06:27,703 --> 00:06:30,490
‫cierto, es una práctica común usar siempre el nombre

139
00:06:30,490 --> 00:06:34,820
‫del recurso en plural, por lo que tengo / tours aquí y no / tour.

140
00:06:34,820 --> 00:06:37,790
‫Ahora, la convención es que al llamar a ese punto

141
00:06:37,790 --> 00:06:41,820
‫final, recuperamos todos los recorridos que están en una base de datos, ¿de acuerdo?

142
00:06:41,820 --> 00:06:44,820
‫Pero si solo queremos la gira con un yo. D. digamos siete, agregamos

143
00:06:44,820 --> 00:06:48,960
‫ese siete después de otra barra o en una consulta de búsqueda.

144
00:06:48,960 --> 00:06:50,580
‫O también podría ser el nombre de una gira en lugar del I. D. o algún otro identificador único.

145
00:06:50,580 --> 00:06:53,490
‫El detalle realmente no importa en este punto, ¿de acuerdo?

146
00:06:53,490 --> 00:06:55,410
‫Más adelante, les mostraré lo

147
00:06:55,410 --> 00:06:58,300
‫fácil que es implementar este tipo de lógica con

148
00:06:58,300 --> 00:07:01,180
‫Express porque aquí es donde Express realmente brilla.

149
00:07:01,180 --> 00:07:03,410
‫El primer método HTTP o verbo

150
00:07:03,410 --> 00:07:06,733
‫al que podemos responder es GET y se usa para

151
00:07:07,606 --> 00:07:10,460
‫realizar la operación de lectura en los datos.

152
00:07:10,460 --> 00:07:12,530
‫Siguiente parada, si el cliente

153
00:07:12,530 --> 00:07:16,290
‫desea crear un nuevo recurso en nuestra base de datos,

154
00:07:16,290 --> 00:07:18,290
‫en este ejemplo, un

155
00:07:18,290 --> 00:07:21,450
‫nuevo recorrido, se debe utilizar el método POST.

156
00:07:21,450 --> 00:07:23,200
‫Entonces, aprendimos anteriormente que una solicitud

157
00:07:23,200 --> 00:07:25,510
‫POST se puede usar para enviar datos

158
00:07:25,510 --> 00:07:28,490
‫al servidor, por lo que tiene sentido usar POST para

159
00:07:28,490 --> 00:07:30,230
‫crear nuevos recursos, ¿verdad?

160
00:07:30,230 --> 00:07:32,270
‫Ahora, en este caso, normalmente no yo. D. se enviará porque

161
00:07:32,270 --> 00:07:35,530
‫el servidor debería averiguar automáticamente el

162
00:07:35,530 --> 00:07:38,530
‫I. D. para el nuevo recurso.

163
00:07:38,530 --> 00:07:40,860
‫De todos modos, lo que es realmente importante tener en cuenta aquí es cómo el nombre del punto final es exactamente

164
00:07:40,860 --> 00:07:42,948
‫el mismo nombre que antes.

165
00:07:42,948 --> 00:07:46,090
‫La única diferencia es realmente

166
00:07:46,090 --> 00:07:50,289
‫el método HTP que se utiliza para la solicitud.

167
00:07:50,289 --> 00:07:53,870
‫Si se accede al punto final / tours con

168
00:07:53,870 --> 00:07:55,960
‫GET, enviamos datos al cliente.

169
00:07:55,960 --> 00:07:59,410
‫Pero si se accede al mismo punto final con POST, esperamos

170
00:07:59,410 --> 00:08:01,460
‫que los datos ingresen con

171
00:08:01,460 --> 00:08:04,060
‫una solicitud, de modo que podamos crear un

172
00:08:04,060 --> 00:08:06,550
‫nuevo recurso en el lado del servidor.

173
00:08:06,550 --> 00:08:08,760
‫Así que esa es realmente la belleza de usar solo métodos HTTP en lugar de

174
00:08:08,760 --> 00:08:10,330
‫jugar con verbos en los nombres de los extremos.

175
00:08:10,330 --> 00:08:14,460
‫Una vez más, se volvería realmente inmanejable muy rápido.

176
00:08:14,460 --> 00:08:17,480
‫Muy bien, a continuación, también

177
00:08:17,480 --> 00:08:21,210
‫debería existir la posibilidad de actualizar los recursos.

178
00:08:21,210 --> 00:08:23,620
‫Y para eso, se debe realizar

179
00:08:23,620 --> 00:08:26,390
‫una solicitud PUT o PATCH al punto

180
00:08:26,390 --> 00:08:27,310
‫final.

181
00:08:27,310 --> 00:08:29,550
‫La diferencia entre ellos es que con

182
00:08:29,550 --> 00:08:31,550
‫PUT, se supone que el cliente

183
00:08:31,550 --> 00:08:33,750
‫envía todo el objeto actualizado, mientras que

184
00:08:33,750 --> 00:08:37,280
‫con PATCH, se supone que envía solo la parte del objeto que

185
00:08:37,280 --> 00:08:38,370
‫se ha cambiado.

186
00:08:38,370 --> 00:08:40,967
‫Pero ambos tienen la capacidad de

187
00:08:40,967 --> 00:08:43,060
‫enviar datos al servidor.

188
00:08:43,060 --> 00:08:45,140
‫Un poco como POST, en realidad, pero con una intención diferente.

189
00:08:45,140 --> 00:08:46,750
‫Entonces, POST es crear

190
00:08:46,750 --> 00:08:50,750
‫un nuevo recurso, mientras que PUT o PATCH se usan para

191
00:08:50,750 --> 00:08:53,070
‫actualizar un recurso existente y, por

192
00:08:53,070 --> 00:08:55,370
‫lo tanto, hace toda la diferencia.

193
00:08:55,370 --> 00:08:57,500
‫Y finalmente, para el recurso

194
00:08:57,500 --> 00:08:59,660
‫de basura, está el método DELETE HTTP.

195
00:08:59,660 --> 00:09:02,110
‫Una vez más, el I. D. o algún otro identificador único del recurso

196
00:09:02,110 --> 00:09:05,110
‫que se va a eliminar debe formar parte de

197
00:09:05,110 --> 00:09:08,010
‫la URL.

198
00:09:08,010 --> 00:09:10,120
‫Ahora, por lo general, para

199
00:09:10,120 --> 00:09:11,820
‫poder realizar este tipo

200
00:09:11,820 --> 00:09:14,560
‫de solicitud, el cliente debe estar autenticado.

201
00:09:14,560 --> 00:09:16,610
‫Entonces, básicamente, inicie sesión en su aplicación, ¿de acuerdo?

202
00:09:16,610 --> 00:09:18,620
‫Pero ese es, por supuesto, un tema para mucho más tarde.

203
00:09:18,620 --> 00:09:21,670
‫Entonces, estos son los cinco métodos HTTP a

204
00:09:21,670 --> 00:09:24,349
‫los que podemos y debemos responder

205
00:09:24,349 --> 00:09:27,080
‫cuando construimos nuestras API RESTful para que

206
00:09:27,080 --> 00:09:29,320
‫el cliente pueda realizar

207
00:09:29,320 --> 00:09:31,570
‫las cuatro operaciones CRUD básicas.

208
00:09:31,570 --> 00:09:33,270
‫Entonces CRUD significa Crear, Leer, Actualizar y Eliminar.

209
00:09:33,270 --> 00:09:36,290
‫Y verá este término todo

210
00:09:36,290 --> 00:09:40,730
‫el tiempo relacionado con API y bases de datos.

211
00:09:40,730 --> 00:09:42,590
‫Y verá que estos métodos HTTP

212
00:09:42,590 --> 00:09:45,200
‫se asignan bastante bien a las operaciones CRUD básicas.

213
00:09:45,200 --> 00:09:47,490
‫Ahora bien, puede haber

214
00:09:47,490 --> 00:09:51,330
‫acciones que no sean CRUD, y en ese caso,

215
00:09:51,330 --> 00:09:54,410
‫solo necesitamos ser creativos con nuestras aportaciones.

216
00:09:54,410 --> 00:09:55,460
‫Por ejemplo, un inicio

217
00:09:55,460 --> 00:09:58,120
‫de sesión o una operación de búsqueda, estos no

218
00:09:58,120 --> 00:09:58,953
‫están realmente

219
00:09:58,953 --> 00:10:01,010
‫relacionados con un recurso en particular y

220
00:10:01,010 --> 00:10:04,361
‫tampoco son operaciones CRUD, pero aún podemos crear puntos finales para ellos.

221
00:10:04,361 --> 00:10:06,630
‫Por ejemplo, como / login o / search.

222
00:10:06,630 --> 00:10:09,240
‫Pero hablaremos más sobre estos casos más adelante en la práctica.

223
00:10:09,240 --> 00:10:12,530
‫Y solo para terminar esta parte ahora, recuerde

224
00:10:12,530 --> 00:10:16,350
‫que teníamos otros dos nombres de puntos finales locos en

225
00:10:16,350 --> 00:10:18,290
‫la última diapositiva que

226
00:10:18,290 --> 00:10:21,330
‫involucraban dos recursos al mismo tiempo, ¿verdad?

227
00:10:21,330 --> 00:10:23,870
‫Y eso tampoco es un problema con REST.

228
00:10:23,870 --> 00:10:26,780
‫Entonces, / getToursByUser simplemente se

229
00:10:26,780 --> 00:10:29,888
‫puede traducir a / users /

230
00:10:29,888 --> 00:10:33,810
‫tours, en este caso, el usuario número tres.

231
00:10:33,810 --> 00:10:36,210
‫Entonces, este punto final en particular aquí podría

232
00:10:36,210 --> 00:10:38,440
‫enviar datos sobre todos los recorridos que el

233
00:10:38,440 --> 00:10:40,200
‫usuario número tres ha reservado.

234
00:10:40,200 --> 00:10:42,340
‫¿Tiene sentido?

235
00:10:42,340 --> 00:10:44,580
‫O en el caso de eliminar, podría haber una

236
00:10:44,580 --> 00:10:45,519
‫solicitud de eliminación

237
00:10:45,519 --> 00:10:47,470
‫para el mismo punto final o uno

238
00:10:47,470 --> 00:10:50,170
‫muy similar, solicitando que el tour número nueve se elimine

239
00:10:50,170 --> 00:10:51,910
‫del usuario número tres, ¿de acuerdo?

240
00:10:51,910 --> 00:10:54,440
‫Entonces, realmente hay un montón

241
00:10:54,440 --> 00:10:57,330
‫de posibilidades de combinar recursos como este.

242
00:10:57,330 --> 00:11:00,160
‫Pero, por supuesto, no tenemos que implementar todas

243
00:11:00,160 --> 00:11:02,470
‫estas combinaciones en nuestra API.

244
00:11:02,470 --> 00:11:04,260
‫Solo implementamos lo que tiene

245
00:11:04,260 --> 00:11:06,600
‫sentido en el caso de nuestra aplicación y

246
00:11:06,600 --> 00:11:08,400
‫el cliente que quiere consumir nuestra API.

247
00:11:08,400 --> 00:11:10,090
‫Entonces, así es como

248
00:11:10,090 --> 00:11:13,203
‫usamos los métodos HTTP para crear URL fáciles de usar

249
00:11:13,203 --> 00:11:17,480
‫y bien estructuradas que son fáciles y lógicas de consumir para el cliente.

250
00:11:17,480 --> 00:11:20,823
‫Ahora, sobre los datos que el cliente realmente

251
00:11:20,823 --> 00:11:24,145
‫recibe, o que el servidor recibe

252
00:11:24,145 --> 00:11:27,800
‫del cliente, usualmente usamos el formato de datos JSON.

253
00:11:27,800 --> 00:11:30,610
‫Entonces, aprendamos brevemente qué es JSON en realidad

254
00:11:30,610 --> 00:11:33,203
‫y cómo formatear nuestras respuestas API.

255
00:11:34,440 --> 00:11:37,400
‫JSON es un formato de intercambio de datos

256
00:11:37,400 --> 00:11:39,530
‫muy ligero que es muy

257
00:11:39,530 --> 00:11:43,780
‫utilizado por las API web codificadas en cualquier lenguaje de programación.

258
00:11:43,780 --> 00:11:46,220
‫Así que simplemente no está relacionado con JavaScript.

259
00:11:46,220 --> 00:11:48,160
‫Y es tan ampliamente utilizado hoy en

260
00:11:48,160 --> 00:11:50,740
‫día porque es realmente fácil para los humanos y

261
00:11:50,740 --> 00:11:52,620
‫las computadoras entender y escribir JSON.

262
00:11:52,620 --> 00:11:55,930
‫Así que probablemente ya estés notando que JSON se parece un poco

263
00:11:55,930 --> 00:11:57,990
‫a un objeto JavaScript normal, ¿verdad?

264
00:11:57,990 --> 00:12:00,510
‫Con todos estos pares clave-valor.

265
00:12:00,510 --> 00:12:04,020
‫Sin embargo, existen algunas diferencias y la más

266
00:12:04,020 --> 00:12:06,470
‫importante es que todas las claves

267
00:12:06,470 --> 00:12:08,320
‫deben ser cadenas.

268
00:12:08,320 --> 00:12:10,960
‫También es muy típico que los valores también sean

269
00:12:10,960 --> 00:12:12,580
‫cadenas, pero pueden ser

270
00:12:12,580 --> 00:12:14,730
‫otras cosas como números, valores verdaderos o

271
00:12:14,730 --> 00:12:17,440
‫falsos, otro objeto o incluso matrices de otros valores.

272
00:12:17,440 --> 00:12:20,690
‫De hecho, es bastante sencillo.

273
00:12:20,690 --> 00:12:23,328
‫Y a partir de este ejemplo, puede ver

274
00:12:23,328 --> 00:12:25,790
‫cómo se vería un JSON típico.

275
00:12:25,790 --> 00:12:27,070
‫Digamos que estos

276
00:12:27,070 --> 00:12:30,883
‫son datos que tenemos en nuestra base de datos para una solicitud

277
00:12:31,890 --> 00:12:35,290
‫GET a esta URL, por lo que el recorrido con I. D. de cinco.

278
00:12:35,290 --> 00:12:38,560
‫Ahora, podríamos devolverlo así al cliente, pero generalmente

279
00:12:38,560 --> 00:12:41,440
‫hacemos un

280
00:12:41,440 --> 00:12:44,300
‫formato de respuesta simple antes de enviarlo.

281
00:12:44,300 --> 00:12:47,130
‫Hay un par de estándares para esto y usaremos uno

282
00:12:47,130 --> 00:12:48,620
‫muy simple llamado Jsend.

283
00:12:48,620 --> 00:12:50,880
‫Simplemente creamos un nuevo objeto, luego

284
00:12:50,880 --> 00:12:54,570
‫le agregamos un mensaje de estado para informar al cliente

285
00:12:54,570 --> 00:12:56,320
‫si la solicitud

286
00:12:56,320 --> 00:12:58,310
‫fue exitosa, fallida o errónea,

287
00:12:58,310 --> 00:13:00,740
‫y luego colocamos nuestros datos originales en

288
00:13:00,740 --> 00:13:03,350
‫un nuevo objeto llamado Datos, ¿de acuerdo?

289
00:13:03,350 --> 00:13:05,390
‫Y podemos desarrollar esto

290
00:13:05,390 --> 00:13:08,510
‫un poco más, pero esta es realmente la forma

291
00:13:08,510 --> 00:13:10,640
‫más sencilla de formatear con Jsend.

292
00:13:10,640 --> 00:13:12,020
‫Y, por cierto, empaquetar los

293
00:13:12,020 --> 00:13:14,250
‫datos en un objeto adicional como lo hicimos

294
00:13:14,250 --> 00:13:15,240
‫aquí se

295
00:13:15,240 --> 00:13:17,550
‫llama Enveloping, y es una práctica común para

296
00:13:17,550 --> 00:13:19,860
‫mitigar algunos problemas de seguridad y otros problemas.

297
00:13:19,860 --> 00:13:21,470
‫Además, existen otros

298
00:13:21,470 --> 00:13:25,550
‫estándares para el formato de respuesta que puede consultar, como Jsend: API

299
00:13:25,550 --> 00:13:27,200
‫o el protocolo Odata JSON.

300
00:13:27,200 --> 00:13:30,330
‫Muy bien, y finalmente, una

301
00:13:30,330 --> 00:13:34,333
‫API RESTful siempre debe ser sin estado.

302
00:13:35,800 --> 00:13:37,470
‫Entonces, ¿qué significa realmente apátrida?

303
00:13:37,470 --> 00:13:40,720
‫Bueno, en una API RESTful sin estado, todo

304
00:13:40,720 --> 00:13:43,170
‫el estado se maneja en

305
00:13:43,170 --> 00:13:45,960
‫el cliente y no en el servidor.

306
00:13:45,960 --> 00:13:48,410
‫Y el estado simplemente se refiere a un dato en la

307
00:13:48,410 --> 00:13:50,120
‫aplicación que puede cambiar con el tiempo.

308
00:13:50,120 --> 00:13:52,910
‫Por ejemplo, si un determinado usuario está conectado

309
00:13:52,910 --> 00:13:55,750
‫o en una página con una lista con

310
00:13:55,750 --> 00:13:56,583
‫varias

311
00:13:56,583 --> 00:13:58,720
‫páginas, cuál es la página actual.

312
00:13:58,720 --> 00:14:02,230
‫Ahora bien, el hecho de que el estado deba manejarse

313
00:14:02,230 --> 00:14:04,150
‫en el cliente significa que

314
00:14:04,150 --> 00:14:06,170
‫cada solicitud debe contener toda la

315
00:14:06,170 --> 00:14:09,910
‫información necesaria para procesar una determinada solicitud en el servidor, ¿de acuerdo?

316
00:14:09,910 --> 00:14:12,710
‫¿Tiene sentido?

317
00:14:12,710 --> 00:14:15,780
‫Por lo tanto, el servidor nunca debería

318
00:14:15,780 --> 00:14:17,170
‫tener que

319
00:14:17,170 --> 00:14:21,030
‫recordar la solicitud anterior para procesar la solicitud actual.

320
00:14:21,030 --> 00:14:24,010
‫Tomemos como ejemplo la lista con varias páginas.

321
00:14:24,010 --> 00:14:25,906
‫Y digamos eso de forma

322
00:14:25,906 --> 00:14:29,670
‫recurrente en la página cinco y queremos pasar a la página seis.

323
00:14:29,670 --> 00:14:32,980
‫Entonces podríamos tener un punto final simple llamado /

324
00:14:32,980 --> 00:14:36,006
‫tours / nextPage y enviarle una solicitud, ¿verdad?

325
00:14:36,006 --> 00:14:39,710
‫Pero el servidor tendría que averiguar cuál es la

326
00:14:40,650 --> 00:14:43,400
‫página actual y, basándose en eso, enviar

327
00:14:43,400 --> 00:14:45,610
‫la página siguiente al cliente.

328
00:14:45,610 --> 00:14:48,450
‫En otras palabras, el servidor debería

329
00:14:48,450 --> 00:14:50,496
‫recordar la solicitud anterior.

330
00:14:50,496 --> 00:14:51,730
‫Tendría que manejar

331
00:14:51,730 --> 00:14:54,950
‫el lado del servidor de estado y eso es exactamente lo

332
00:14:54,950 --> 00:14:57,640
‫que queremos evitar en las API RESTful, ¿de acuerdo?

333
00:14:57,640 --> 00:15:00,260
‫En su lugar, en este caso, deberíamos

334
00:15:00,260 --> 00:15:03,120
‫crear un punto final de / tours /

335
00:15:03,120 --> 00:15:04,630
‫page y pegarle el

336
00:15:04,630 --> 00:15:07,550
‫número seis para solicitar la página número seis.

337
00:15:07,550 --> 00:15:09,410
‫De esta manera, luego indicaríamos en el

338
00:15:09,410 --> 00:15:11,850
‫cliente porque en un cliente, ya sabríamos que estamos

339
00:15:11,850 --> 00:15:14,340
‫en la página cinco, por lo que todo lo

340
00:15:14,340 --> 00:15:15,410
‫que teníamos que

341
00:15:15,410 --> 00:15:18,320
‫hacer es agregar uno y luego solicitar la página número seis.

342
00:15:18,320 --> 00:15:20,750
‫Entonces, el servidor no tiene que recordar

343
00:15:20,750 --> 00:15:22,750
‫nada en este caso.

344
00:15:22,750 --> 00:15:23,920
‫Todo lo que tiene que hacer

345
00:15:23,920 --> 00:15:25,840
‫es enviar los datos de la página número seis como lo solicitamos.

346
00:15:25,840 --> 00:15:27,940
‫Y por cierto, la apatridia y

347
00:15:27,940 --> 00:15:30,840
‫la estatalidad, que es lo contrario, son conceptos

348
00:15:30,840 --> 00:15:33,891
‫muy importantes en la informática y el diseño

349
00:15:33,891 --> 00:15:35,760
‫de aplicaciones en general.

350
00:15:35,760 --> 00:15:38,560
‫Por lo tanto, es una buena idea comprender qué es

351
00:15:38,560 --> 00:15:40,800
‫una API sin estado y cómo funciona.

352
00:15:40,800 --> 00:15:44,070
‫De todos modos, esta fue una gran conferencia,

353
00:15:44,070 --> 00:15:47,331
‫pero también una de las más importantes.

354
00:15:47,331 --> 00:15:50,280
‫No puedo enfatizar eso lo suficiente y de hecho

355
00:15:50,280 --> 00:15:52,670
‫creo que puedes ver eso, ¿verdad?

356
00:15:52,670 --> 00:15:55,700
‫De todos modos, regresemos finalmente a nuestro código.