1
00:00:00,000 --> 00:00:03,979
[MÚSICA]

2
00:00:03,979 --> 00:00:06,750
Déjame darte un breve descanso.

3
00:00:08,010 --> 00:00:09,480
¡Te tengo ahí!

4
00:00:09,480 --> 00:00:10,800
Lo que quise decir fue,

5
00:00:10,800 --> 00:00:16,860
permítanme darles una breve visión general de la transferencia de estado representacional.

6
00:00:16,860 --> 00:00:18,670
¿Qué es exactamente el descanso?

7
00:00:18,670 --> 00:00:22,900
¿Cómo lo hacemos en nuestra aplicación angular y

8
00:00:22,900 --> 00:00:26,450
cómo hacemos uso de esto para comunicarnos con el servidor?

9
00:00:26,450 --> 00:00:30,050
¿Cómo admite un servidor REST API y

10
00:00:30,050 --> 00:00:35,060
cómo accedemos a la API REST desde nuestra aplicación angular?

11
00:00:35,060 --> 00:00:39,170
Hablemos de eso un poco más en esta lección.

12
00:00:39,170 --> 00:00:43,880
En esta conferencia en particular, les daré una breve visión general de REST.

13
00:00:46,010 --> 00:00:50,620
Estoy seguro de que ha escuchado el término Servicios Web siendo mencionado

14
00:00:50,620 --> 00:00:53,990
en el mundo de TI muy a menudo.

15
00:00:53,990 --> 00:00:56,160
¿Qué son exactamente los servicios web?

16
00:00:56,160 --> 00:01:01,980
Los servicios web son una forma de diseñar sistemas que soporten la interoperabilidad entre sistemas

17
00:01:01,980 --> 00:01:07,920
conectados a través de una red, como Internet como vemos hoy.

18
00:01:07,920 --> 00:01:11,830
Esto es lo que nos referimos como una arquitectura orientada al servicio.

19
00:01:11,830 --> 00:01:18,100
Ahora, lo que esto significa es que usted proporciona una forma estandarizada para que dos máquinas

20
00:01:18,100 --> 00:01:22,190
que están conectadas a Internet puedan comunicarse entre sí.

21
00:01:23,670 --> 00:01:26,970
Su nivel de diseño de aplicaciones para aplicaciones de base de datos

22
00:01:26,970 --> 00:01:30,920
usando estándares abiertos.

23
00:01:30,920 --> 00:01:34,660
Ahora, he usado mucha jerga allí.

24
00:01:35,710 --> 00:01:37,420
Vamos a tratar de descomponerlos y

25
00:01:37,420 --> 00:01:41,640
entender un poco acerca de cada uno de ellos en esta conferencia.

26
00:01:42,640 --> 00:01:49,570
Dos enfoques comunes que se utilizan para admitir servicios web son SOAP,

27
00:01:49,570 --> 00:01:54,720
los servicios web basados en el protocolo de acceso a objetos simples,

28
00:01:54,720 --> 00:01:58,820
que utiliza el lenguaje de descripción de servicios web para

29
00:01:58,820 --> 00:02:03,150
especificando cómo los dos puntos finales se comunican entre sí.

30
00:02:03,150 --> 00:02:07,667
Y normalmente, soap se basa en el uso de XML como

31
00:02:07,667 --> 00:02:12,240
el formato para los mensajes que se intercambian entre los dos extremos.

32
00:02:13,990 --> 00:02:19,910
La transferencia de estado de presentación o descanso también utiliza estándares web, pero el intercambio

33
00:02:19,910 --> 00:02:24,020
de datos entre los dos extremos podría ser XML o cada vez más.

34
00:02:25,150 --> 00:02:28,960
Usando JSON como formato.

35
00:02:28,960 --> 00:02:34,960
La forma REST de interoperabilidad es más simple en comparación con SOAP y

36
00:02:34,960 --> 00:02:42,940
, por lo tanto, REST ha encontrado una implementación mucho más amplia en los servicios web que quedan.

37
00:02:43,950 --> 00:02:49,230
Normalmente, la comunicación con el servidor cliente se facilita mediante REST

38
00:02:49,230 --> 00:02:54,830
, donde el servidor admite la API REST y el cliente puede invocar sus extremos de API REST

39
00:02:54,830 --> 00:03:01,000
para obtener información o cargar información en el servidor.

40
00:03:01,000 --> 00:03:05,910
Una vez más, he mencionado la palabra, invoque ese punto final de la API REST.

41
00:03:05,910 --> 00:03:09,290
Así que estos son algunos términos que he usado.

42
00:03:09,290 --> 00:03:12,460
Aclaremos algunos de estos en las próximas diapositivas.

43
00:03:13,790 --> 00:03:18,710
La transferencia de estado representacional es un estilo de arquitectura de software que

44
00:03:18,710 --> 00:03:23,360
está especialmente diseñado para hipermedios distribuidos a través de la World Wide Web.

45
00:03:24,770 --> 00:03:30,810
Ahora esto fue introducido por primera vez por Roy Fielding en su tesis doctoral.

46
00:03:30,810 --> 00:03:33,750
Ahora, esta es una de esas tesis doctorales que realmente produjo

47
00:03:33,750 --> 00:03:35,970
algo útil para el mundo.

48
00:03:35,970 --> 00:03:44,250
Así que esto ha encontrado de nuevo mucha tracción en el mundo de los servicios web.

49
00:03:44,250 --> 00:03:50,410
Esta es una colección de principios de red que describen cómo los recursos pueden estar

50
00:03:51,630 --> 00:03:57,060
disponibles en los servidores, y se puede acceder a estos recursos desde los clientes

51
00:03:57,060 --> 00:04:02,520
identificando los recursos utilizando los puntos finales de la API REST.

52
00:04:02,520 --> 00:04:07,150
Dentro de la Transferencia de Estado Representacional hay cuatro principios básicos de diseño.

53
00:04:07,150 --> 00:04:11,310
En primer lugar, REST se basa en el protocolo HTTP.

54
00:04:11,310 --> 00:04:17,800
Así que utiliza todos los métodos HTTP que ya hemos visto en la lección anterior.

55
00:04:17,800 --> 00:04:22,750
En segundo lugar, REST está diseñado para ser sin estado, lo que significa que el servidor no almacena

56
00:04:22,750 --> 00:04:27,350
ninguna información sobre el estado después de completar la comunicación.

57
00:04:27,350 --> 00:04:31,850
Así que cuando un servidor recibe la solicitud, el servidor responde y

58
00:04:31,850 --> 00:04:37,020
después de eso, no recuerda nada más sobre esa conversación

59
00:04:37,020 --> 00:04:39,730
entre el cliente y el servidor.

60
00:04:39,730 --> 00:04:44,620
En tercer lugar, la forma REST de proporcionar recursos es

61
00:04:44,620 --> 00:04:49,990
exponer una estructura de directorio como URL de localizadores de recursos uniformes URL.

62
00:04:51,090 --> 00:04:57,210
Y en cuarto lugar, su formato para el intercambio de datos es típicamente JSON o

63
00:04:57,210 --> 00:05:02,360
XML, o ambos que pueden ser compatibles con REST.

64
00:05:02,360 --> 00:05:07,940
Una de las motivaciones para subir sugiriendo REST como una forma de apoyar servicios web

65
00:05:07,940 --> 00:05:14,060
es que captura todo lo que es bueno de toda la World Wide Web.

66
00:05:14,060 --> 00:05:17,130
Y eso hizo que Word Wide Web fuera un éxito.

67
00:05:17,130 --> 00:05:23,240
El uso de Indicadores Uniformes de Recursos o Localizadores Uniformes de Recursos, URL,

68
00:05:23,240 --> 00:05:28,660
que le permiten dirigir recursos especificándolos como una URL,

69
00:05:28,660 --> 00:05:35,370
el segundo es un protocolo que se desplaza sobre el protocolo HTTP.

70
00:05:35,370 --> 00:05:40,820
HTTP ya ha encontrado una amplia implementación en Internet.

71
00:05:40,820 --> 00:05:46,370
Tercero, el ciclo de respuesta de solicitud por el que HTTP es bien conocido.

72
00:05:46,370 --> 00:05:51,850
Así que usted envía una solicitud, el servidor recibe su solicitud, procesa la solicitud,

73
00:05:51,850 --> 00:05:57,835
envía la respuesta a la solicitud, y ese cliente recibe la respuesta,

74
00:05:57,835 --> 00:06:00,845
actúa sobre eso, y puede generar más solicitudes.

75
00:06:00,845 --> 00:06:06,815
Por lo tanto, este enfoque del ciclo de respuesta de solicitudes está muy bien establecido con HTTP

76
00:06:06,815 --> 00:06:14,740
y el protocolo HTTP Web THe en todo el mundo como hemos visto anteriormente,

77
00:06:14,740 --> 00:06:19,670
vamos a utilizar todos los verbos que HTTP proporciona.

78
00:06:19,670 --> 00:06:23,120
Específicamente, la puerta puso post eliminar.

79
00:06:23,120 --> 00:06:26,730
Para poder especificar las operaciones a realizar

80
00:06:26,730 --> 00:06:29,680
en los recursos que se almacenan en el lado del servidor.

81
00:06:29,680 --> 00:06:34,320
Entonces, por ejemplo, si realiza una solicitud HTTP GET, está pidiendo

82
00:06:34,320 --> 00:06:36,180
el servidor para devolver el origen.

83
00:06:36,180 --> 00:06:41,410
Si realiza una solicitud POST, está pidiendo que el servidor cree un nuevo recurso.

84
00:06:41,410 --> 00:06:44,330
Si realiza una solicitud PUT, está pidiendo al servidor que actualice

85
00:06:44,330 --> 00:06:48,780
un recurso existente y si emite una solicitud de eliminación, está pidiendo

86
00:06:48,780 --> 00:06:54,210
el servidor para eliminar el recurso identificado por esa URL en particular.

87
00:06:54,210 --> 00:06:57,890
Además, trata de preservar la idempotencia.

88
00:06:57,890 --> 00:07:00,970
Algunas operaciones cuando se realizan

89
00:07:00,970 --> 00:07:04,370
Incluso repetidamente no causarán ningún cambio de estado.

90
00:07:04,370 --> 00:07:08,160
Otras operaciones, si las haces sucesivamente,

91
00:07:08,160 --> 00:07:11,170
pueden causar un cambio de estado.

92
00:07:11,170 --> 00:07:14,780
Así que debe tener cuidado con qué operaciones se pueden repetir sin

93
00:07:14,780 --> 00:07:16,660
ninguna consecuencia perjudicial.

94
00:07:16,660 --> 00:07:19,570
Y que hay que hacer con mucho cuidado.

95
00:07:21,070 --> 00:07:25,530
En el mundo REST, a menudo escuchas a la gente hablando de sustantivos, verbos

96
00:07:25,530 --> 00:07:28,230
y representaciones.

97
00:07:28,230 --> 00:07:34,120
Ahora aclararemos cada una de ellas con un poco más de detalle en las próximas diapositivas.

98
00:07:34,120 --> 00:07:36,720
sustantivos, específicamente, están llenos de recursos y

99
00:07:36,720 --> 00:07:42,580
estos recursos suelen ser identificados por sus URL y estos son sin restricciones.

100
00:07:42,580 --> 00:07:48,890
Los verbos están restringidos y estas acciones especificadas se deben realizar en los recursos.

101
00:07:48,890 --> 00:07:53,200
Y las presentaciones como vemos cuando la información necesita ser transmitida desde

102
00:07:53,200 --> 00:07:54,560
el servidor al cliente o

103
00:07:54,560 --> 00:07:58,150
desde el cliente al servidor, cómo codifica la información.

104
00:07:58,150 --> 00:08:02,840
Normalmente, ya sea usando JSON o usando XML.

105
00:08:02,840 --> 00:08:08,150
Resource es la abstracción clave a la que REST trabaja para que

106
00:08:08,150 --> 00:08:11,787
la información se abstrae en el recurso.

107
00:08:11,787 --> 00:08:18,690
Y el recurso se identifica especificándolo mediante un URI.

108
00:08:18,690 --> 00:08:23,040
Por lo tanto, cualquier información que pueda ser encapsulada y

109
00:08:23,040 --> 00:08:26,980
estar disponible puede ser identificada como un recurso.

110
00:08:26,980 --> 00:08:33,145
Un pedazo de información como ese clima actual en Hong Kong podría ser un recurso,

111
00:08:33,145 --> 00:08:35,465
una imagen podría ser un recurso.

112
00:08:35,465 --> 00:08:39,915
Una información sobre el precio de las acciones podría ser un recurso, y así sucesivamente.

113
00:08:39,915 --> 00:08:43,905
Así que cualquier cosa que definas como una información en la que un cliente puede estar

114
00:08:43,905 --> 00:08:47,515
interesado, puede ser identificado como un recurso.

115
00:08:47,515 --> 00:08:50,965
Incluso puede tratar con recursos como colección de recursos

116
00:08:50,965 --> 00:08:55,070
que ese servidor puede enviar hasta ese cliente.

117
00:08:55,070 --> 00:09:00,380
Aquí se ilustra un ejemplo de cómo nombra recursos.

118
00:09:00,380 --> 00:09:03,898
Así que usamos URI para identificar la fuente.

119
00:09:03,898 --> 00:09:09,575
Una lectura rápida de la especificación o las URL aquí

120
00:09:09,575 --> 00:09:16,525
le permitirá comprender fácilmente a qué nos referimos mediante el uso de estas URL.

121
00:09:16,525 --> 00:09:19,675
Así, por ejemplo, algo que termina con platos/,

122
00:09:19,675 --> 00:09:25,495
automáticamente asumes que esto se refiere a una colección de platos.

123
00:09:25,495 --> 00:09:28,909
Como platos/123 por ejemplo,

124
00:09:28,909 --> 00:09:34,150
podría significar el plato número 123, en este caso y así sucesivamente.

125
00:09:34,150 --> 00:09:39,530
Así que es muy fácil decir que puede especificar una colección de recursos, y

126
00:09:39,530 --> 00:09:43,800
ser capaz de identificarlos como una colección, y luego descargarlos como una colección.

127
00:09:43,800 --> 00:09:46,960
O bien, puede identificar un recurso individual, y

128
00:09:46,960 --> 00:09:50,070
decir que desea ese recurso en particular.

129
00:09:50,070 --> 00:09:53,378
Ahora estos recursos se pueden organizar en una jerarquía

130
00:09:53,378 --> 00:09:56,500
esa especificación de este URI.

131
00:09:56,500 --> 00:09:58,860
Así que a medida que atraviesas el camino,

132
00:09:58,860 --> 00:10:04,460
vas de lo más general a lo más específico de ese recurso.

133
00:10:04,460 --> 00:10:08,260
Esta estructura de directorios le permite identificar fácilmente los recursos que

134
00:10:09,320 --> 00:10:14,170
proporciona desde su sitio de servicio.

135
00:10:14,170 --> 00:10:17,970
La segunda parte de la API REST son las palabras.

136
00:10:17,970 --> 00:10:22,150
En particular estamos interesados en los 4 verbos de HTTP para obtener,

137
00:10:22,150 --> 00:10:25,320
poner, publicar y eliminar.

138
00:10:25,320 --> 00:10:30,310
En este caso, estos verbos serán siesta en las acciones que

139
00:10:30,310 --> 00:10:36,165
queremos realizar en el recurso en el lado del servidor.

140
00:10:36,165 --> 00:10:40,760
GetT significaría que desea realizar una operación de lectura en el recurso, lo que significa

141
00:10:40,760 --> 00:10:46,550
que un cliente que envía una solicitud get indica al servidor que desea

142
00:10:46,550 --> 00:10:52,710
obtener esa presentación del origen de datos desde el sitio del servidor al sitio del cliente.

143
00:10:52,710 --> 00:10:56,770
POST significa que desea crear un nuevo recurso y luego lo hará.

144
00:10:56,770 --> 00:11:01,700
Especifique los detalles del recurso en la representación, pero se utiliza para

145
00:11:01,700 --> 00:11:02,850
especificando el recurso.

146
00:11:02,850 --> 00:11:05,900
A continuación, envíe la información al lado del servidor, de modo que

147
00:11:05,900 --> 00:11:09,590
el servidor creará el recurso en su nombre.

148
00:11:09,590 --> 00:11:12,310
Un PUT sería una modificación de recursos, y

149
00:11:12,310 --> 00:11:16,030
eliminar, como era de esperar, es la eliminación de las fuentes.

150
00:11:16,030 --> 00:11:20,550
Así que, como se puede ver los cuatro Verbos obtener, publicar, poner y

151
00:11:20,550 --> 00:11:25,670
delete se asignan a las cuatro operaciones CRUD que puede llevar a cabo

152
00:11:25,670 --> 00:11:30,140
en una base de datos que almacena estos recursos en el lado del servidor.

153
00:11:30,140 --> 00:11:34,130
Las operaciones de lectura, creación, actualización y eliminación.

154
00:11:34,130 --> 00:11:39,140
Elaborando más, HTTP GET es una forma de especificar.

155
00:11:39,140 --> 00:11:43,560
Que desea que la información o su presentación del recurso sea

156
00:11:43,560 --> 00:11:46,280
devuelta al cliente desde el sitio del servidor.

157
00:11:46,280 --> 00:11:49,980
Entonces, cuando emita una solicitud GET a un punto final de API REST.

158
00:11:49,980 --> 00:11:54,370
Usted está pidiendo ya sea una colección de recursos que se presentan por

159
00:11:55,890 --> 00:12:01,790
Uri o un recurso específico que se identifica por el ID de

160
00:12:01,790 --> 00:12:06,950
que los recursos particulares especificados dentro de la URL tal como se ve en este ejemplo,

161
00:12:06,950 --> 00:12:13,090
si platos/452, quiere decir que el plato número 452,

162
00:12:13,090 --> 00:12:16,950
con el id 452 debe devolverse al lado del cliente.

163
00:12:19,370 --> 00:12:24,210
Del mismo modo, la operación posterior, como vimos, se usa para crear el recurso.

164
00:12:24,210 --> 00:12:29,940
Entonces, cuando crea el recurso, el contenido de describir el recurso sería

165
00:12:29,940 --> 00:12:34,830
en forma de una representación JSON o una representación XML, y eso sería

166
00:12:34,830 --> 00:12:40,220
incluido en el cuerpo del mensaje de solicitud que se envía al lado del servidor.

167
00:12:40,220 --> 00:12:43,900
Por lo tanto, una operación posterior espera una representación

168
00:12:43,900 --> 00:12:49,040
del recurso en formato JSON o XML en el cuerpo del mensaje de solicitud.

169
00:12:49,040 --> 00:12:53,250
Y el servidor recibe dicho mensaje de solicitud, el servidor crea ese recurso

170
00:12:53,250 --> 00:12:58,440
en el lado del servidor y luego devuelve una confirmación o

171
00:12:58,440 --> 00:13:04,390
un error para indicar que la creación del recurso falló.

172
00:13:04,390 --> 00:13:08,820
Del mismo modo, puso la operación fácil de usar para actualizar un recurso.

173
00:13:08,820 --> 00:13:14,630
Cuando realiza una operación PUT en un recurso en el lado del servidor, puede devolver

174
00:13:14,630 --> 00:13:19,630
la modificación especificando sólo la modificación parcial

175
00:13:19,630 --> 00:13:25,450
que desea aplicar en el recurso particular en el cuerpo del mensaje de respuesta.

176
00:13:25,450 --> 00:13:29,370
O puede enviar la representación completa del recurso

177
00:13:29,370 --> 00:13:33,890
en el cuerpo del mensaje, dependiendo de la disposición entre el cliente y

178
00:13:33,890 --> 00:13:38,760
el servidor, el servidor espera que la información se transmita

179
00:13:38,760 --> 00:13:43,320
en el cuerpo del mensaje de solicitud.

180
00:13:43,320 --> 00:13:48,980
operación DELETE como era de esperar elimina el recurso existente.

181
00:13:48,980 --> 00:13:55,150
Ahora, en este caso particular, por supuesto, una operación de eliminación sería porque

182
00:13:55,150 --> 00:14:00,220
si intenta eliminar un recurso y el recurso existe, se eliminará.

183
00:14:00,220 --> 00:14:02,440
Si intenta eliminar un recurso no existente,

184
00:14:02,440 --> 00:14:07,990
no causará ninguna modificación adicional en el lado del servidor Excepto

185
00:14:07,990 --> 00:14:11,808
que el servidor responderá con un error diciendo que el recurso no existe.

186
00:14:11,808 --> 00:14:18,700
Pero sin embargo, es un ejemplo de una operación en este caso.

187
00:14:18,700 --> 00:14:22,810
Del mismo modo, la operación get también funcionará porque no es

188
00:14:22,810 --> 00:14:27,140
haciendo ninguna modificación en el recurso en el sitio del servidor.

189
00:14:27,140 --> 00:14:32,740
Post input, por supuesto, va a modificar el recurso en el lado del servidor.

190
00:14:32,740 --> 00:14:34,770
Necesita crear un nuevo recurso o

191
00:14:34,770 --> 00:14:40,050
modificar el recurso existente en el lado del servidor y, por supuesto, presentaciones de datos del curso.

192
00:14:40,050 --> 00:14:45,050
Como he estado enfatizando, los dos retrocesos comunes para

193
00:14:45,050 --> 00:14:51,570
que representa es JSON XML, la última parte

194
00:14:51,570 --> 00:14:57,140
que debemos enfatizar es que el lado del servidor debe ser completamente apátrida.

195
00:14:57,140 --> 00:15:01,190
Lo que significa que el lado del servidor no realiza un seguimiento del estado del cliente.

196
00:15:01,190 --> 00:15:07,060
Porque, si el servidor necesita realizar un seguimiento del estado del cliente, no será escalable.

197
00:15:07,060 --> 00:15:11,140
Entonces, para una implementación escalable del lado del servidor,

198
00:15:11,140 --> 00:15:15,650
normalmente usa un servidor sin estado en el lado del servidor.

199
00:15:15,650 --> 00:15:19,580
Así que si la solicitud de los clientes enviados al servidor será tratada como

200
00:15:19,580 --> 00:15:25,460
una solicitud independiente, y no reflejará en las solicitudes

201
00:15:25,460 --> 00:15:30,790
anteriores que ya han sido manejadas por el servidor desde el cliente en particular.

202
00:15:30,790 --> 00:15:35,760
Así que es responsabilidad del cliente rastrear su propio estado.

203
00:15:35,760 --> 00:15:40,770
Ya sea en forma de uso de cookies o utilizando una base de datos del sitio cliente.

204
00:15:40,770 --> 00:15:43,780
Lo que significa que es adecuado.

205
00:15:43,780 --> 00:15:48,760
Ahora, este enfoque en el que el cliente realiza un seguimiento de su propio estado es mucho más escalable,

206
00:15:48,760 --> 00:15:52,880
porque su cliente será responsable del seguimiento del suyo propio.

207
00:15:54,340 --> 00:15:58,880
Y aquí es donde la configuración MVC del lado del cliente nos ayuda en este sentido.

208
00:16:00,100 --> 00:16:04,920
Y finalmente aún no hemos terminado con REST, veremos más de

209
00:16:04,920 --> 00:16:10,280
REST en los ejercicios que siguen en esta lección particular.

210
00:16:10,280 --> 00:16:11,563
Y luego también,

211
00:16:11,563 --> 00:16:17,206
veremos más detalles sobre el uso de REST en el resto de este curso.

212
00:16:17,206 --> 00:16:20,509
[MÚSICA]