1
00:00:03,200 --> 00:00:09,035
Déjame darte un breve descanso. Te tengo ahí.

2
00:00:09,035 --> 00:00:11,535
Lo que quise decir es que les dé

3
00:00:11,535 --> 00:00:16,420
una breve visión general de la Transferencia Estatal Representacional.

4
00:00:16,420 --> 00:00:18,460
¿ Qué es exactamente REST?

5
00:00:18,460 --> 00:00:22,670
¿ Cómo hacemos uso de ella en nuestra aplicación React,

6
00:00:22,670 --> 00:00:26,130
y cómo hacemos uso de esto para comunicarnos con el servidor?

7
00:00:26,130 --> 00:00:29,455
¿ Cómo admite un servidor la API REST

8
00:00:29,455 --> 00:00:34,615
y cómo accedemos a la API REST desde nuestra aplicación React?

9
00:00:34,615 --> 00:00:39,230
Hablemos de eso un poco más en esta lección.

10
00:00:39,230 --> 00:00:47,680
Estoy seguro de que ha escuchado el término servicios web que se menciona en el mundo de TI muy a menudo.

11
00:00:47,680 --> 00:00:49,895
¿ Qué son exactamente los servicios web?

12
00:00:49,895 --> 00:00:55,520
Los servicios web son una forma de diseñar sistemas para apoyar la interoperabilidad

13
00:00:55,520 --> 00:01:01,745
entre sistemas que están conectados a través de una red como Internet, tal como vemos hoy en día.

14
00:01:01,745 --> 00:01:05,504
Esto es a lo que nos referimos como una arquitectura orientada a servicios.

15
00:01:05,504 --> 00:01:09,170
Ahora, lo que esto significa es que proporciona

16
00:01:09,170 --> 00:01:14,870
una forma estandarizada para que dos máquinas que están conectadas a Internet puedan

17
00:01:14,870 --> 00:01:17,720
comunicarse entre sí a

18
00:01:17,720 --> 00:01:24,660
nivel de aplicación para aplicaciones basadas en web utilizando estándares abiertos.

19
00:01:24,660 --> 00:01:29,175
Ahora, he usado mucha jerga allí.

20
00:01:29,175 --> 00:01:32,000
Tratemos de desglosarlos y entender

21
00:01:32,000 --> 00:01:36,195
un poco acerca de cada uno de ellos en esta conferencia.

22
00:01:36,195 --> 00:01:43,390
Dos enfoques comunes que se utilizan para admitir servicios web son SOAP.

23
00:01:43,390 --> 00:01:49,550
Los servicios web basados en Protocolo simple de acceso a objetos que utiliza

24
00:01:49,550 --> 00:01:52,805
el lenguaje de descripción de servicios web para

25
00:01:52,805 --> 00:01:57,080
especificar cómo los dos extremos se comunican entre sí.

26
00:01:57,080 --> 00:02:01,700
Normalmente, SOAP se basa en

27
00:02:01,700 --> 00:02:07,340
el uso de XML como formato para los mensajes que se intercambian entre los dos extremos.

28
00:02:07,340 --> 00:02:12,975
Representational State Transfer o REST también utiliza estándares web,

29
00:02:12,975 --> 00:02:17,240
pero el intercambio de datos entre los dos extremos podría ser XML o

30
00:02:17,240 --> 00:02:22,385
utilizar cada vez más JSON como formato.

31
00:02:22,385 --> 00:02:29,705
La forma REST de interoperabilidad es más simple en comparación con SOAP y, por lo tanto,

32
00:02:29,705 --> 00:02:37,650
REST ha encontrado una implementación mucho más amplia en el mundo de los servicios web.

33
00:02:37,650 --> 00:02:41,215
Normalmente, la comunicación cliente-servidor se

34
00:02:41,215 --> 00:02:45,830
facilita mediante REST, donde el servidor admite una API REST y

35
00:02:45,830 --> 00:02:49,960
el cliente puede entonces invocar los extremos de la API REST

36
00:02:49,960 --> 00:02:54,595
para obtener información o cargar información en el servidor.

37
00:02:54,595 --> 00:02:59,885
Una vez más, he mencionado la palabra invocar los extremos de la API REST,

38
00:02:59,885 --> 00:03:03,210
por lo que estos son algunos términos que he usado.

39
00:03:03,210 --> 00:03:07,385
Vamos a aclarar algunas de estas en las próximas diapositivas.

40
00:03:07,385 --> 00:03:12,590
La transferencia de estado representacional es un estilo de arquitectura de software

41
00:03:12,590 --> 00:03:18,200
que está especialmente diseñado para hipermedios distribuidos a través de la World Wide Web.

42
00:03:18,200 --> 00:03:24,604
Esto fue introducido por primera vez por Roy Fielding en su tesis doctoral.

43
00:03:24,604 --> 00:03:26,990
Esta es una de esas tesis de doctorado

44
00:03:26,990 --> 00:03:29,660
que realmente produjo algo útil para el mundo.

45
00:03:29,660 --> 00:03:38,690
Así que esto ha encontrado de nuevo una gran cantidad de tracción en el mundo de los servicios web.

46
00:03:38,690 --> 00:03:42,800
Esta es una colección de principios de red que describen cómo

47
00:03:42,800 --> 00:03:47,300
los recursos pueden estar disponibles en los servidores

48
00:03:47,300 --> 00:03:50,950
y a estos recursos se puede acceder desde los clientes

49
00:03:50,950 --> 00:03:56,285
mediante la identificación de los recursos mediante extremos de API de descanso.

50
00:03:56,285 --> 00:03:58,855
Dentro de la Transferencia de Estado Representacional,

51
00:03:58,855 --> 00:04:01,050
existen cuatro principios básicos de diseño.

52
00:04:01,050 --> 00:04:05,375
En primer lugar, REST se basa en el protocolo HTTP,

53
00:04:05,375 --> 00:04:11,365
por lo que utiliza todos los métodos HTTP que ya hemos visto en la lección anterior.

54
00:04:11,365 --> 00:04:15,045
En segundo lugar, REST está diseñado para ser sin estado,

55
00:04:15,045 --> 00:04:17,930
lo que significa que el servidor no almacena ninguna información sobre

56
00:04:17,930 --> 00:04:21,450
el estado después de que se complete la comunicación.

57
00:04:21,450 --> 00:04:25,615
Entonces, cuando un servidor recibe la solicitud, el servidor responde,

58
00:04:25,615 --> 00:04:29,110
y luego no recuerda

59
00:04:29,110 --> 00:04:33,340
nada más sobre la conversación entre el cliente y el servidor.

60
00:04:33,340 --> 00:04:38,635
En tercer lugar, la forma REST de proporcionar recursos es

61
00:04:38,635 --> 00:04:44,945
exponer una estructura de directorios como URLs (Uniform Resource Locators - URLs).

62
00:04:44,945 --> 00:04:50,230
En cuarto lugar, el formato para el intercambio de datos suele ser JSON

63
00:04:50,230 --> 00:04:56,145
o XML o ambos pueden ser compatibles con REST.

64
00:04:56,145 --> 00:05:03,350
Una de las motivaciones para que Roy sugiera REST como una forma de apoyar los servicios web

65
00:05:03,350 --> 00:05:06,620
es que captura todas las cosas que son buenas sobre

66
00:05:06,620 --> 00:05:10,880
la World Wide Web y que hizo que la World Wide Web tuviera éxito.

67
00:05:10,880 --> 00:05:14,040
El uso de indicadores uniformes de recursos o

68
00:05:14,040 --> 00:05:18,320
localizadores uniformes de recursos (URL) que permiten

69
00:05:18,320 --> 00:05:23,170
abordar los recursos especificándolos como una dirección URL.

70
00:05:23,170 --> 00:05:29,390
El segundo, siendo un protocolo que vive en la parte superior del protocolo HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP ya ha encontrado una amplia implementación en Internet.

72
00:05:34,600 --> 00:05:40,135
En tercer lugar, el ciclo de respuesta de solicitud por el que HTTP es conocido.

73
00:05:40,135 --> 00:05:42,420
Por lo tanto, envía una solicitud,

74
00:05:42,420 --> 00:05:45,775
el servidor recibe su solicitud, procesa

75
00:05:45,775 --> 00:05:49,530
la solicitud, envía la respuesta a la solicitud,

76
00:05:49,530 --> 00:05:51,830
y el cliente recibe la respuesta,

77
00:05:51,830 --> 00:05:54,765
actúa sobre eso y puede generar más solicitudes.

78
00:05:54,765 --> 00:05:58,580
Por lo tanto, este enfoque del ciclo de respuesta de solicitudes está muy

79
00:05:58,580 --> 00:06:03,115
bien establecido con HTTP y la World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Ahora, el protocolo HTTP como hemos visto anteriormente,

81
00:06:08,505 --> 00:06:13,650
vamos a utilizar todos los diversos verbos que HTTP proporciona.

82
00:06:13,650 --> 00:06:15,520
específicamente, GET,

83
00:06:15,520 --> 00:06:18,635
PUT, POST y DELETE para poder

84
00:06:18,635 --> 00:06:23,480
especificar las operaciones que se deben realizar en los recursos que se almacenan en el lado del servidor.

85
00:06:23,480 --> 00:06:27,470
Entonces, por ejemplo, si hace una solicitud HTTP GET,

86
00:06:27,470 --> 00:06:30,125
está pidiendo que el servidor devuelva el recurso.

87
00:06:30,125 --> 00:06:32,415
Si realiza una solicitud POST,

88
00:06:32,415 --> 00:06:35,415
está pidiendo que el servidor cree un nuevo recurso.

89
00:06:35,415 --> 00:06:36,670
Si realiza una solicitud PUT,

90
00:06:36,670 --> 00:06:39,650
solicita al servidor que actualice un recurso existente.

91
00:06:39,650 --> 00:06:42,170
Y si emite una solicitud DELETE,

92
00:06:42,170 --> 00:06:45,020
está pidiendo al servidor

93
00:06:45,020 --> 00:06:48,070
que elimine el recurso identificado por la URL en particular.

94
00:06:48,070 --> 00:06:51,735
Además, trata de preservar Idempotencia.

95
00:06:51,735 --> 00:06:56,165
Algunas operaciones, cuando se realizan incluso repetidamente,

96
00:06:56,165 --> 00:06:58,225
no causarán ningún cambio de estado.

97
00:06:58,225 --> 00:07:02,085
Algunas otras operaciones, si las hace sucesivamente,

98
00:07:02,085 --> 00:07:05,170
pueden causar un cambio de estado.

99
00:07:05,170 --> 00:07:08,780
Por lo tanto, debe tener cuidado con qué operaciones se pueden repetir

100
00:07:08,780 --> 00:07:14,395
sin consecuencias perjudiciales y cuáles deben hacerse con mucho cuidado.

101
00:07:14,395 --> 00:07:21,864
En el mundo REST a menudo escuchas a la gente hablando de sustantivos, verbos y representaciones.

102
00:07:21,864 --> 00:07:27,875
Ahora, aclararemos cada una de ellas con un poco más de detalle en las próximas diapositivas.

103
00:07:27,875 --> 00:07:31,760
Los sustantivos se refieren específicamente a los recursos y estos recursos

104
00:07:31,760 --> 00:07:36,320
suelen ser identificados por sus direcciones URL y estos no están restringidos.

105
00:07:36,320 --> 00:07:40,700
Los verbos son restricciones y estos especifican las acciones que se deben

106
00:07:40,700 --> 00:07:45,010
realizar en los recursos y representaciones como vemos.

107
00:07:45,010 --> 00:07:47,285
Cuando la información necesita ser transmitida desde

108
00:07:47,285 --> 00:07:49,910
el servidor al cliente o desde el cliente al servidor,

109
00:07:49,910 --> 00:07:51,855
cómo codifica la información.

110
00:07:51,855 --> 00:07:56,520
Normalmente, ya sea usando JSON o usando XML. El

111
00:07:56,520 --> 00:08:01,895
recurso es la abstracción clave en la que REST trabaja.

112
00:08:01,895 --> 00:08:06,810
Por lo tanto, la información se abstrae en forma de un recurso y el recurso

113
00:08:06,810 --> 00:08:12,475
se identifica especificándolo mediante una URL.

114
00:08:12,475 --> 00:08:18,395
Por lo tanto, cualquier información que se pueda encapsular y poner a disposición,

115
00:08:18,395 --> 00:08:20,720
se puede identificar como un recurso.

116
00:08:20,720 --> 00:08:26,980
Una información como el clima actual en Hong Kong podría ser un recurso, una

117
00:08:26,980 --> 00:08:29,345
imagen podría ser un recurso,

118
00:08:29,345 --> 00:08:33,985
una información sobre el precio de las acciones podría ser un recurso y así sucesivamente. Por

119
00:08:33,985 --> 00:08:38,920
lo tanto, lo que defina como una pieza de información en la que un cliente puede estar interesado,

120
00:08:38,920 --> 00:08:41,430
puede ser identificado como un recurso.

121
00:08:41,430 --> 00:08:44,045
Incluso puede tratar con los recursos como colección de

122
00:08:44,045 --> 00:08:48,740
recursos que el servidor puede enviar al cliente.

123
00:08:48,740 --> 00:08:54,145
Aquí se ilustra un ejemplo de cómo se asignan nombres a los recursos.

124
00:08:54,145 --> 00:08:57,740
Así que usamos URI para identificar la fuente.

125
00:08:57,740 --> 00:09:03,355
Una lectura rápida de estas especificaciones o de los URI aquí

126
00:09:03,355 --> 00:09:10,460
le permitirá comprender fácilmente a qué nos estamos refiriendo mediante el uso de estos URI.

127
00:09:10,460 --> 00:09:14,420
Entonces, por ejemplo, algo que termina con platos/,

128
00:09:14,420 --> 00:09:19,315
automáticamente asumes que esto se refiere a una colección de platos.

129
00:09:19,315 --> 00:09:22,795
Pero platos/123, por ejemplo,

130
00:09:22,795 --> 00:09:28,250
podría significar plato número 123 en este caso y así sucesivamente. Por

131
00:09:28,250 --> 00:09:31,320
lo tanto, es muy fácil de guardar y puede especificar

132
00:09:31,320 --> 00:09:34,650
una colección de recursos y ser capaz de

133
00:09:34,650 --> 00:09:38,815
identificarlos como una colección y luego descargarlos como una colección o puede

134
00:09:38,815 --> 00:09:43,965
identificar un recurso individual y decir que desea ese recurso en particular.

135
00:09:43,965 --> 00:09:50,395
Ahora, estos recursos se pueden organizar en una jerarquía de la especificación de este URI.

136
00:09:50,395 --> 00:09:52,740
Por lo tanto, a medida que atraviesa

137
00:09:52,740 --> 00:09:58,325
la ruta, pasa de lo más general a lo más específico del recurso.

138
00:09:58,325 --> 00:10:02,110
Esta estructura de directorios le permite identificar

139
00:10:02,110 --> 00:10:07,780
fácilmente los recursos que utiliza o proporciona desde el lado del servidor.

140
00:10:07,780 --> 00:10:11,585
La segunda parte de la API REST son los verbos.

141
00:10:11,585 --> 00:10:16,760
En particular, estamos interesados en los cuatro verbos de HTTP el GET,

142
00:10:16,760 --> 00:10:19,140
PUT, POST y DELETE.

143
00:10:19,140 --> 00:10:24,410
En este caso, estos verbos se asignarán a acciones que

144
00:10:24,410 --> 00:10:29,755
queremos realizar en el recurso, en el lado del servidor.

145
00:10:29,755 --> 00:10:34,170
Un GET significaría que desea realizar una operación de lectura en el recurso.

146
00:10:34,170 --> 00:10:39,980
Por lo tanto, lo que significa que un cliente que envía una solicitud GET está indicando

147
00:10:39,980 --> 00:10:43,480
al servidor que desea obtener una representación

148
00:10:43,480 --> 00:10:46,380
de ese recurso desde el lado del servidor al lado del cliente.

149
00:10:46,380 --> 00:10:48,960
Un POST significa que desea crear

150
00:10:48,960 --> 00:10:52,755
un nuevo recurso y, a continuación, especificará los detalles del recurso

151
00:10:52,755 --> 00:10:55,795
en la representación que se utiliza para

152
00:10:55,795 --> 00:10:59,799
especificar el recurso y, a continuación, enviará esa información al lado del servidor, de

153
00:10:59,799 --> 00:11:03,285
modo que el servidor creará ese recurso en su nombre.

154
00:11:03,285 --> 00:11:06,370
Un PUT sería una modificación de los recursos y

155
00:11:06,370 --> 00:11:09,955
un DELETE como cabría esperar es la eliminación de los recursos.

156
00:11:09,955 --> 00:11:12,995
Así, como puede ver, los cuatro verbos:

157
00:11:12,995 --> 00:11:15,110
GET, POST, PUT y DELETE,

158
00:11:15,110 --> 00:11:19,180
se asignan a las cuatro operaciones CRUD que se pueden

159
00:11:19,180 --> 00:11:24,035
realizar en una base de datos que almacena estos recursos en el lado del servidor,

160
00:11:24,035 --> 00:11:27,815
las operaciones READ, CREATE, UPDATE y DELETE.

161
00:11:27,815 --> 00:11:33,760
Más adelante, HTTP GET es una forma de especificar que

162
00:11:33,760 --> 00:11:36,950
desea que la información o la representación

163
00:11:36,950 --> 00:11:40,235
del recurso se devuelva al cliente desde el lado del servidor.

164
00:11:40,235 --> 00:11:43,890
Por lo tanto, cuando emite una solicitud GET a un extremo de API REST,

165
00:11:43,890 --> 00:11:49,130
está pidiendo una colección de recursos representados por

166
00:11:49,130 --> 00:11:57,530
URI o un recurso específico que se identifica mediante el ID de ese recurso en particular,

167
00:11:57,530 --> 00:11:59,490
especificado dentro de la URL. Por

168
00:11:59,490 --> 00:12:01,000
lo tanto, como puede ver en este ejemplo,

169
00:12:01,000 --> 00:12:03,800
si dice, platos/452,

170
00:12:03,800 --> 00:12:08,320
quiere decir que el plato número 452 con

171
00:12:08,320 --> 00:12:13,075
el ID 452 debe devolverse al lado del cliente.

172
00:12:13,075 --> 00:12:18,175
Del mismo modo, la operación POST tal como vimos se utiliza para crear el recurso.

173
00:12:18,175 --> 00:12:20,065
Por lo tanto, al crear el recurso,

174
00:12:20,065 --> 00:12:26,920
el contenido de describir el recurso sería en forma de una representación JSON o

175
00:12:26,920 --> 00:12:29,790
una representación XML y que se incluirá en

176
00:12:29,790 --> 00:12:34,075
el cuerpo del mensaje de solicitud que se envía al lado del servidor.

177
00:12:34,075 --> 00:12:38,095
Por lo tanto, una operación POST espera una representación

178
00:12:38,095 --> 00:12:42,870
del recurso en formato JSON o XML en el cuerpo del mensaje de solicitud.

179
00:12:42,870 --> 00:12:44,890
Cuando el servidor recibe ese mensaje de solicitud,

180
00:12:44,890 --> 00:12:49,960
el servidor crea ese recurso en el lado del servidor y, a continuación, devuelve

181
00:12:49,960 --> 00:12:58,030
una conformación o un error para indicar que la creación del recurso falló.

182
00:12:58,030 --> 00:13:02,725
Del mismo modo, se utiliza una operación PUT para actualizar un recurso.

183
00:13:02,725 --> 00:13:06,315
Cuando realiza una operación PUT en un recurso en el lado del servidor,

184
00:13:06,315 --> 00:13:10,200
puede devolver la modificación

185
00:13:10,200 --> 00:13:15,470
especificando sólo la modificación parcial que desea aplicar en

186
00:13:15,470 --> 00:13:20,200
el recurso particular en el cuerpo del mensaje de respuesta o puede enviar

187
00:13:20,200 --> 00:13:25,345
la representación completa del en el cuerpo del mensaje.

188
00:13:25,345 --> 00:13:28,705
Dependiendo de la disposición entre el cliente y el servidor,

189
00:13:28,705 --> 00:13:37,195
el servidor espera que la información se transmita en el cuerpo del mensaje de solicitud.

190
00:13:37,195 --> 00:13:42,600
Una operación DELETE como cabría esperar elimina el recurso existente.

191
00:13:42,600 --> 00:13:45,460
Ahora, en este caso particular,

192
00:13:45,460 --> 00:13:49,670
por supuesto, una operación DELETE sería idempotente porque si

193
00:13:49,670 --> 00:13:54,145
intenta eliminar un recurso y el recurso existe, se eliminará.

194
00:13:54,145 --> 00:13:56,445
Si está intentando eliminar un recurso no existente,

195
00:13:56,445 --> 00:14:01,220
no causará ninguna modificación adicional en el lado del servidor,

196
00:14:01,220 --> 00:14:06,165
excepto que el servidor responderá con un error que indica que el recurso no existe.

197
00:14:06,165 --> 00:14:12,530
Pero, sin embargo, DELETE es un ejemplo de una operación idempotente en este caso.

198
00:14:12,530 --> 00:14:16,510
Del mismo modo, la operación GET también es una operación idempotente porque

199
00:14:16,510 --> 00:14:20,885
no está realizando ninguna modificación en el recurso en el lado del servidor.

200
00:14:20,885 --> 00:14:26,925
POST y PUT, por supuesto, van a modificar el recurso en el lado del servidor,

201
00:14:26,925 --> 00:14:31,940
ya sea crear un nuevo recurso o modificar un recurso existente en el lado del servidor.

202
00:14:31,940 --> 00:14:34,060
Por supuesto, las representaciones,

203
00:14:34,060 --> 00:14:36,730
como he estado enfatizando,

204
00:14:36,730 --> 00:14:43,980
los dos formatos comunes para representar son JSON o XML.

205
00:14:43,980 --> 00:14:47,105
La última parte que debemos enfatizar es

206
00:14:47,105 --> 00:14:51,060
que el lado del servidor debe ser completamente sin estado,

207
00:14:51,060 --> 00:14:53,640
lo que significa que el lado del servidor no realiza un seguimiento

208
00:14:53,640 --> 00:14:59,145
del estado del cliente porque si el servidor necesita rastrear el estado de los clientes,

209
00:14:59,145 --> 00:15:00,935
no será escalable.

210
00:15:00,935 --> 00:15:05,160
Por lo tanto, para una implementación escalable del lado del servidor,

211
00:15:05,160 --> 00:15:09,620
normalmente usa un servidor sin estado en el lado del servidor.

212
00:15:09,620 --> 00:15:12,910
Por lo tanto, cada solicitud que el cliente envía al servidor será

213
00:15:12,910 --> 00:15:16,490
tratada como una solicitud independiente y

214
00:15:16,490 --> 00:15:20,330
no se reflejará en solicitudes anteriores

215
00:15:20,330 --> 00:15:24,685
que ya han sido manejadas por el servidor desde ese cliente en particular.

216
00:15:24,685 --> 00:15:29,605
Por lo tanto, es responsabilidad del cliente rastrear su propio estado,

217
00:15:29,605 --> 00:15:34,635
ya sea en forma de uso de cookies o utilizando una base de datos del lado del cliente,

218
00:15:34,635 --> 00:15:37,435
cualquiera que sea el medio adecuado.

219
00:15:37,435 --> 00:15:41,790
Ahora, este enfoque donde el cliente realiza

220
00:15:41,790 --> 00:15:44,815
un seguimiento de su propio estado es mucho más escalable porque cada cliente individual

221
00:15:44,815 --> 00:15:48,240
será responsable de rastrear su propio estado.

222
00:15:48,240 --> 00:15:53,840
Aquí es donde la configuración de MVC del lado del cliente nos ayuda en este sentido.

223
00:15:53,840 --> 00:15:57,440
Por último, aún no hemos terminado con REST.

224
00:15:57,440 --> 00:16:04,145
Veremos más de REST en los ejercicios que siguen en esta lección en particular

225
00:16:04,145 --> 00:16:12,310
y luego también veremos más detalles sobre el uso de REST en el resto de este curso.