1 00:00:03,880 --> 00:00:06,815 Permítanme comenzar dándoles 2 00:00:06,815 --> 00:00:11,165 una introducción rápida de 10 minutos a lo esencial de las redes. 3 00:00:11,165 --> 00:00:14,045 Dado el hecho de que tenemos un tiempo limitado, 4 00:00:14,045 --> 00:00:16,355 me concentraría en entregarle 5 00:00:16,355 --> 00:00:21,191 lo esencial que necesita para comprender cada uno de los temas. 6 00:00:21,191 --> 00:00:26,240 Ahora, lo que cubrimos en este módulo en particular requerirá 7 00:00:26,240 --> 00:00:30,230 al menos una comprensión rudimentaria de cómo 8 00:00:30,230 --> 00:00:34,255 funciona la red informática antes de entender por 9 00:00:34,255 --> 00:00:36,700 qué necesitamos usar HTTP, por qué nos comunicamos con un servidor, 10 00:00:36,700 --> 00:00:42,485 cuál es la razón del retraso cuando se habla con un servidor, etc. 11 00:00:42,485 --> 00:00:45,920 Y también, los diversos protocolos que 12 00:00:45,920 --> 00:00:50,335 debe tener en cuenta antes de que pueda comunicarse con un servidor. 13 00:00:50,335 --> 00:00:53,540 Por lo tanto, teniendo todo esto en cuenta, 14 00:00:53,540 --> 00:00:58,945 una rápida introducción de 10 minutos a los Essentials of Networking. 15 00:00:58,945 --> 00:01:03,600 Comenzamos a darnos cuenta de que las aplicaciones web ya no son independientes. 16 00:01:03,600 --> 00:01:11,030 Siempre tienen un backend de la nube sin comillas que respalda su aplicación web. 17 00:01:11,030 --> 00:01:13,535 Ahora, en estos días, todo está en la Nube. 18 00:01:13,535 --> 00:01:15,500 Muy pronto estarás en la Nube también, 19 00:01:15,500 --> 00:01:19,455 al menos en la Nube 9 con un forro plateado. 20 00:01:19,455 --> 00:01:23,785 Pero, dado que necesitamos 21 00:01:23,785 --> 00:01:29,090 un soporte del lado del servidor para que nuestra aplicación angular funcione correctamente, 22 00:01:29,090 --> 00:01:31,295 allí alojaría el servidor. 23 00:01:31,295 --> 00:01:36,405 Y en la actualidad, el alojamiento del servidor se 24 00:01:36,405 --> 00:01:42,575 realiza muy fácilmente utilizando uno de los servicios de infraestructura basados en la nube, 25 00:01:42,575 --> 00:01:48,260 elementos como Amazon Web Services o Heroku u u Digital 26 00:01:48,260 --> 00:01:55,190 Ocean, u otros muchos que proporcionan soporte de servidor basado en la nube. 27 00:01:55,190 --> 00:01:59,235 Entonces, ¿qué está disponible exactamente en el lado del servidor? 28 00:01:59,235 --> 00:02:06,744 Por lo general, tiene un frontend de servidor que está hablando con su aplicación angular, 29 00:02:06,744 --> 00:02:14,615 por lo que esa es la lógica del servidor y detrás de las escenas la lógica del servidor se comunica con 30 00:02:14,615 --> 00:02:23,665 un almacenamiento persistente como una base de datos donde se almacenan y recuperan sus datos. 31 00:02:23,665 --> 00:02:26,130 Cuando entras en el mundo de las redes, 32 00:02:26,130 --> 00:02:31,064 pronto serás bombardeado con 304 pequeños acrónimos, 33 00:02:31,064 --> 00:02:36,230 cosas que pensabas que sabías lo que eran del inglés normal o que tienen 34 00:02:36,230 --> 00:02:38,360 un significado o 35 00:02:38,360 --> 00:02:42,375 propósito completamente diferente cuando te encuentras con ellos en ese mundo de las redes. 36 00:02:42,375 --> 00:02:44,470 Así que vamos a examinar algunos de ellos. 37 00:02:44,470 --> 00:02:49,020 Entonces, en el mundo de las redes, escuchará a la gente hablando a través del protocolo HTTP. 38 00:02:49,020 --> 00:02:53,215 El protocolo que se utiliza para la comunicación entre el cliente y el servidor. 39 00:02:53,215 --> 00:02:56,960 Este es un protocolo de capa de aplicación del que 40 00:02:56,960 --> 00:03:01,135 hablaremos brevemente un poco más en el resto de esta conferencia. 41 00:03:01,135 --> 00:03:07,550 El protocolo HTTP para que funcione necesita una dirección URL que se le proporcione, 42 00:03:07,550 --> 00:03:09,715 el Localizador uniforme de recursos. 43 00:03:09,715 --> 00:03:15,205 Así que esta es una cadena de caracteres separados por barras diagonales, 44 00:03:15,205 --> 00:03:22,355 con dos puntos HTTP o dos puntos HTTPS adjuntos delante de ella. 45 00:03:22,355 --> 00:03:25,547 Y estoy seguro de que si ha utilizado la World Wide Web, 46 00:03:25,547 --> 00:03:29,395 está bastante familiarizado con el aspecto de las URL. 47 00:03:29,395 --> 00:03:33,230 Ahora, además, oirías a la gente hablando de JSON, 48 00:03:33,230 --> 00:03:38,380 no de tu amigo Jason, sino de JavaScript Object Notation. 49 00:03:38,380 --> 00:03:43,610 Por lo tanto, la notación de objetos JavaScript es una forma de codificar los datos que 50 00:03:43,610 --> 00:03:49,660 se envían desde el lado del servidor al lado del cliente o viceversa. 51 00:03:49,660 --> 00:03:54,320 Y también escuchará a la gente hablando de XML otra forma de 52 00:03:54,320 --> 00:04:01,205 codificar datos mientras está en tránsito entre el lado del cliente y el servidor. 53 00:04:01,205 --> 00:04:08,375 Ahora, también escuchará a la gente hablando de protocolos de nivel superior llamados SOAP, 54 00:04:08,375 --> 00:04:14,045 no del tipo con el que se toma una ducha, sino SOAP como un protocolo que 55 00:04:14,045 --> 00:04:21,975 permite la comunicación entre entidades de distribución dentro de su red. 56 00:04:21,975 --> 00:04:25,295 Y también, usted escuchará a la gente hablando de REST, 57 00:04:25,295 --> 00:04:29,505 no algo que se obtiene demasiado pasando por este curso en particular, 58 00:04:29,505 --> 00:04:32,510 REST o Transferencia Estatal Representacional. 59 00:04:32,510 --> 00:04:36,200 Tendré una conferencia más corta 60 00:04:36,200 --> 00:04:40,970 dedicada específicamente a REST un poco más adelante en este módulo. 61 00:04:40,970 --> 00:04:42,905 Y en el mundo HTTP, 62 00:04:42,905 --> 00:04:45,990 oirías a la gente hablando de GET, 63 00:04:45,990 --> 00:04:50,210 PUT, POST y DELETE y te preguntarías, 64 00:04:50,210 --> 00:04:52,200 ¿qué significan todos ellos? 65 00:04:52,200 --> 00:04:55,250 Vamos a aprender un poco sobre estos en 66 00:04:55,250 --> 00:05:01,245 esta conferencia y también la conferencia sobre REST que verá un poco más tarde. 67 00:05:01,245 --> 00:05:05,020 Una cosa importante que debe comprender cuando se está 68 00:05:05,020 --> 00:05:10,120 comunicando con un servidor es que la comunicación del servidor cliente 69 00:05:10,120 --> 00:05:15,130 causa una cantidad inesperada de retrasos o una cantidad indeterminada de retardo 70 00:05:15,130 --> 00:05:21,340 mientras los datos se están recuperando o cargando en el servidor desde el sitio del cliente. 71 00:05:21,340 --> 00:05:23,270 Lo que significa que dentro de su aplicación de sitio cliente, 72 00:05:23,270 --> 00:05:27,310 debe mantener al usuario informado sobre el hecho de que 73 00:05:27,310 --> 00:05:31,750 algo está sucediendo entre bastidores y ser 74 00:05:31,750 --> 00:05:35,335 capaz de manejar los retrasos y 75 00:05:35,335 --> 00:05:41,020 posiblemente no ser capaz de obtener los datos desde el lado del servidor. 76 00:05:41,020 --> 00:05:45,490 Es muy posible que cuando intenta conectarse a un servidor, 77 00:05:45,490 --> 00:05:47,765 la conexión del servidor puede fallar, 78 00:05:47,765 --> 00:05:53,920 el servidor puede devolver datos incorrectos o puede causar un error en la comunicación. 79 00:05:53,920 --> 00:05:58,750 Todo esto tiene que ser manejado en el lado del cliente de manera adecuada para que su aplicación 80 00:05:58,750 --> 00:06:04,450 siga funcionando incluso en presencia de estos problemas. 81 00:06:04,450 --> 00:06:09,250 Saltar al protocolo de capa de aplicación más popular 82 00:06:09,250 --> 00:06:12,880 utilizado para la comunicación entre el cliente y el servidor, 83 00:06:12,880 --> 00:06:15,405 el Protocolo de transferencia de hipertexto. 84 00:06:15,405 --> 00:06:18,585 Pero este es un protocolo de comunicación cliente servidor. 85 00:06:18,585 --> 00:06:20,800 Ahora eso puede o no tener mucho sentido para usted a 86 00:06:20,800 --> 00:06:23,532 menos que tenga suficiente experiencia en redes, 87 00:06:23,532 --> 00:06:28,480 pero este es un protocolo que se usa para codificar los mensajes que 88 00:06:28,480 --> 00:06:31,330 intercambió entre su aplicación cliente, que es 89 00:06:31,330 --> 00:06:35,375 una aplicación angular en este caso y un lado del servidor. 90 00:06:35,375 --> 00:06:38,620 Por lo tanto, este protocolo HTTP le permite 91 00:06:38,620 --> 00:06:42,450 recuperar documentos basados en hipertexto desde el lado del servidor, 92 00:06:42,450 --> 00:06:47,200 cada vez más la información que se descarga desde el lado del servidor está 93 00:06:47,200 --> 00:06:52,495 codificada en uno de los formatos de codificación estándar como JSON o XML. 94 00:06:52,495 --> 00:06:55,750 Y para poder hablar con un servidor, 95 00:06:55,750 --> 00:07:04,180 usted tiene el apoyo de varias acciones HTTP o lo que nos referimos como verbos HTTP, 96 00:07:04,180 --> 00:07:07,135 HEAD, GET, POST, PUT, 97 00:07:07,135 --> 00:07:11,020 DELETE, TRACE, OPTIONS y CONNECT. 98 00:07:11,020 --> 00:07:14,080 Veremos en particular los 99 00:07:14,080 --> 00:07:24,395 verbos GET, PUT, POST y DELETE con más detalle cuando examinemos el protocolo REST API un poco más tarde. 100 00:07:24,395 --> 00:07:27,670 ¿ Cómo funciona el protocolo HTTP? 101 00:07:27,670 --> 00:07:30,010 En el protocolo HTTP, 102 00:07:30,010 --> 00:07:35,215 está enviando solicitud GET desde su aplicación cliente al servidor. 103 00:07:35,215 --> 00:07:39,780 Y esto está codificado en forma de un mensaje de solicitud HTTP. 104 00:07:39,780 --> 00:07:43,760 El mensaje de solicitud suele incluir una URL en 105 00:07:43,760 --> 00:07:48,995 el mensaje de solicitud que indica qué es lo que desea que le envíe el lado del servidor. 106 00:07:48,995 --> 00:07:52,660 Y este es típicamente un mensaje GET si desea que 107 00:07:52,660 --> 00:07:57,440 los datos se descarguen desde el lado del servidor. 108 00:07:57,440 --> 00:08:02,110 También especificará con qué servidor concreto se está comunicando. 109 00:08:02,110 --> 00:08:04,864 Cuando el servidor recibe su solicitud, 110 00:08:04,864 --> 00:08:09,325 el servidor recuperará los datos de su almacenamiento de datos, 111 00:08:09,325 --> 00:08:11,980 normalmente una base de datos en el lado del servidor, 112 00:08:11,980 --> 00:08:14,250 y luego empaquetará estos datos en 113 00:08:14,250 --> 00:08:20,420 un formato adecuado y le enviará los datos en el lado del cliente. 114 00:08:20,420 --> 00:08:23,285 Si está obteniendo 115 00:08:23,285 --> 00:08:25,240 código HTML estándar, CSS y JavaScript desde el lado del servidor, 116 00:08:25,240 --> 00:08:27,310 entonces su navegador puede renderizar esto. 117 00:08:27,310 --> 00:08:30,144 Pero con aplicaciones como Angular, 118 00:08:30,144 --> 00:08:32,830 principalmente se está conectando al servidor y luego 119 00:08:32,830 --> 00:08:39,700 recuperando datos en forma de JSON o XML la mayor parte del tiempo. 120 00:08:39,700 --> 00:08:44,200 Excepto por la descarga inicial de todos los recursos necesarios 121 00:08:44,200 --> 00:08:49,245 para que su aplicación Angular se ejecute dentro de su navegador. 122 00:08:49,245 --> 00:08:51,090 Como vimos anteriormente, 123 00:08:51,090 --> 00:08:59,139 la aplicación HTTP requiere que se envíen mensajes entre el cliente y el servidor. 124 00:08:59,139 --> 00:09:03,615 Normalmente, un mensaje de solicitud se envía desde el cliente al servidor y 125 00:09:03,615 --> 00:09:09,500 el mensaje de solicitud consta de una línea de solicitud más un montón de encabezados, 126 00:09:09,500 --> 00:09:14,170 donde se proporciona información adicional para calificar la solicitud. 127 00:09:14,170 --> 00:09:17,410 Veremos el uso de varios encabezados y ajustes en 128 00:09:17,410 --> 00:09:23,425 los encabezados a medida que pasamos por algunos de los ejercicios de este módulo en particular. 129 00:09:23,425 --> 00:09:27,045 La línea de solicitud y los encabezados están separados del cuerpo 130 00:09:27,045 --> 00:09:31,280 del mensaje de solicitud por una línea en blanco. 131 00:09:31,280 --> 00:09:34,300 El cuerpo del mensaje puede contener datos adicionales, 132 00:09:34,300 --> 00:09:38,460 especialmente si su cliente envía datos al lado del servidor. 133 00:09:38,460 --> 00:09:40,735 Por ejemplo, cuando envía un formulario, 134 00:09:40,735 --> 00:09:45,190 la información dentro del formulario se codifica en 135 00:09:45,190 --> 00:09:51,115 un formato JSON y, a continuación, se envía al lado del servidor desde el lado del cliente. 136 00:09:51,115 --> 00:09:55,640 Así que eso se hará usando un mensaje POST o PUT. 137 00:09:55,640 --> 00:10:00,374 Mirando los pequeños detalles del mensaje de solicitud HTTP, 138 00:10:00,374 --> 00:10:02,500 el mensaje de solicitud típico en 139 00:10:02,500 --> 00:10:06,140 la línea de solicitud contendrá el método que es GET, PUT, POST, 140 00:10:06,140 --> 00:10:10,225 DELETE o algunos de los otros verbos que ha visto anteriormente, 141 00:10:10,225 --> 00:10:13,735 y luego seguido por la URL y la versión 142 00:10:13,735 --> 00:10:19,260 del Protocolo HTTP que está utilizando para comunicarse desde el cliente al lado del servidor. 143 00:10:19,260 --> 00:10:23,250 El campo de encabezado generalmente contiene un nombre de campo de encabezado, 144 00:10:23,250 --> 00:10:27,310 dos puntos y el valor de ese campo de encabezado. 145 00:10:27,310 --> 00:10:30,020 Y el contenido del cuerpo, como mencioné, 146 00:10:30,020 --> 00:10:36,090 podría codificarse en formato JSON o XML. 147 00:10:36,090 --> 00:10:39,355 Aquí hay un ejemplo de 148 00:10:39,355 --> 00:10:46,040 un mensaje de solicitud HTTP típico que se puede enviar al servidor desde el cliente. 149 00:10:46,040 --> 00:10:48,000 Entonces, en este mensaje de solicitud en particular, 150 00:10:48,000 --> 00:10:52,540 estamos pidiendo al servidor que retenga la página index.html desde 151 00:10:52,540 --> 00:10:55,150 el lado del servidor hasta el lado del cliente para que 152 00:10:55,150 --> 00:10:58,100 se pueda renderizar en el navegador en el lado del cliente. 153 00:10:58,100 --> 00:11:03,790 Una solicitud como esta normalmente tendría un cuerpo vacío en el mensaje de solicitud. 154 00:11:03,790 --> 00:11:06,460 La mayor parte de la información se codificará en 155 00:11:06,460 --> 00:11:11,755 la línea de solicitud más los encabezados del mensaje de solicitud. 156 00:11:11,755 --> 00:11:15,935 Cuando el cliente envía la solicitud al servidor. 157 00:11:15,935 --> 00:11:22,120 El servidor procesará la solicitud y luego enviará una respuesta al lado del cliente. 158 00:11:22,120 --> 00:11:26,150 El mensaje de respuesta se organiza de nuevo en tres partes, 159 00:11:26,150 --> 00:11:30,850 una línea de estado donde se 160 00:11:30,850 --> 00:11:35,648 almacena información sobre cómo se ha procesado la solicitud y lo que se está enviando al cliente, 161 00:11:35,648 --> 00:11:40,270 los encabezados contendrán detalles adicionales de lo que está 162 00:11:40,270 --> 00:11:45,145 contenido en el mensaje de respuesta y luego seguido de una línea en blanco 163 00:11:45,145 --> 00:11:49,355 y, a continuación, el cuerpo real del mensaje. 164 00:11:49,355 --> 00:11:55,405 Un ejemplo de lo que normalmente estaría contenido en un mensaje de respuesta HTTP, 165 00:11:55,405 --> 00:11:59,875 en este caso, este mensaje de respuesta regresa con un 200, 166 00:11:59,875 --> 00:12:03,260 que es un código de estado del mensaje. 167 00:12:03,260 --> 00:12:07,420 Si ve un 200 en la línea de solicitud como código de estado, 168 00:12:07,420 --> 00:12:11,770 significa que su solicitud se realizó correctamente y el servidor puede 169 00:12:11,770 --> 00:12:16,920 devolver los datos que ha solicitado desde el lado del servidor. 170 00:12:16,920 --> 00:12:22,180 Y luego el encabezado contendrá instrucciones adicionales al 171 00:12:22,180 --> 00:12:25,165 lado del cliente, incluyendo información sobre 172 00:12:25,165 --> 00:12:29,425 cómo se codifica el cuerpo real del mensaje. 173 00:12:29,425 --> 00:12:31,705 A continuación, el cuerpo puede contener, 174 00:12:31,705 --> 00:12:34,565 si ha solicitado la página index.html, 175 00:12:34,565 --> 00:12:39,670 el cuerpo del mensaje contendrá el código HTML de 176 00:12:39,670 --> 00:12:45,515 la página index.html como se ve en este ejemplo aquí. 177 00:12:45,515 --> 00:12:53,955 Una de las piezas de información en la línea de estado a la que me refiero como el código de estado. 178 00:12:53,955 --> 00:12:58,080 Si el servidor puede procesar su solicitud correctamente, 179 00:12:58,080 --> 00:13:01,852 enviará una respuesta con un código de estado de 200, lo que 180 00:13:01,852 --> 00:13:04,330 significa que todo está bien en el lado del servidor y 181 00:13:04,330 --> 00:13:07,685 el lado del servidor devuelve los datos correctamente. 182 00:13:07,685 --> 00:13:12,055 Si el servidor no puede procesar la solicitud por cualquier motivo, 183 00:13:12,055 --> 00:13:14,800 esa información se codificará en 184 00:13:14,800 --> 00:13:20,020 el código de estado en la línea de estado del mensaje de respuesta. 185 00:13:20,020 --> 00:13:24,160 Los diversos códigos de estado que normalmente encontrará cuando 186 00:13:24,160 --> 00:13:28,355 recibe una respuesta del lado del servidor incluyen un 201, 187 00:13:28,355 --> 00:13:30,985 lo que significa que cuando intenta crear 188 00:13:30,985 --> 00:13:34,540 un objeto en el lado del servidor se ha creado con éxito, 189 00:13:34,540 --> 00:13:39,100 o un 301, lo que significa que lo que está solicitando se ha movido permanentemente 190 00:13:39,100 --> 00:13:42,365 a una nueva ubicación y la URL de 191 00:13:42,365 --> 00:13:46,965 la nueva ubicación de ese recurso se devolverá al lado del cliente. 192 00:13:46,965 --> 00:13:52,775 400 y 500 por lo general indican que hay algún problema en el lado del servidor. 193 00:13:52,775 --> 00:13:57,310 404 es algo que a menudo 194 00:13:57,310 --> 00:14:02,260 encuentras cuando solicitas algo que no existe en el lado del servidor. 195 00:14:02,260 --> 00:14:05,620 Del mismo modo, 500 significa que el servidor simplemente se da por vencido, 196 00:14:05,620 --> 00:14:10,390 no puede procesar su solicitud y luego envía de vuelta un error interno del servidor. 197 00:14:10,390 --> 00:14:14,445 Estos son dos códigos de error comunes que encontrará. 198 00:14:14,445 --> 00:14:20,355 Los restantes tienen un significado específico como se indica en esta tabla. 199 00:14:20,355 --> 00:14:24,483 Hay más que los códigos de estado que le di en esta tabla, 200 00:14:24,483 --> 00:14:27,963 pero estos son algunos de los códigos de estado más comunes que 201 00:14:27,963 --> 00:14:32,835 encontrará en un mensaje de respuesta proveniente del lado del servidor. 202 00:14:32,835 --> 00:14:37,420 Otro punto que mencioné es el hecho de que el servidor puede codificar 203 00:14:37,420 --> 00:14:46,880 los datos en un formato específico como XML o Lenguaje de marcado extendido o JSON, 204 00:14:46,880 --> 00:14:50,845 el formato de notación de objetos JavaScript. 205 00:14:50,845 --> 00:14:53,950 Ahora típicamente, en este curso en particular, 206 00:14:53,950 --> 00:14:57,700 trataremos con datos que están codificados principalmente en JSON. 207 00:14:57,700 --> 00:15:02,875 La mayoría de las aplicaciones del lado del cliente 208 00:15:02,875 --> 00:15:06,680 , incluidas las aplicaciones móviles, normalmente se comunican con 209 00:15:06,680 --> 00:15:16,515 el servidor y el formato de intercambio de datos es JSON de forma predeterminada en la mayoría de los casos. 210 00:15:16,515 --> 00:15:22,125 Esa es la razón por la que voy a pasar unos minutos explicándole sobre JSON. 211 00:15:22,125 --> 00:15:27,785 La notación de objetos JavaScript o JSON es un formato de intercambio de datos ligero. 212 00:15:27,785 --> 00:15:33,100 La razón por la que el formato de datos JSON es específicamente de 213 00:15:33,100 --> 00:15:38,685 interés para nosotros en este curso es porque la notación de objetos JavaScript, 214 00:15:38,685 --> 00:15:40,710 como su nombre lo indica, 215 00:15:40,710 --> 00:15:46,840 se asigna muy fácilmente a un objeto JavaScript que usa con cualquier código JavaScript. 216 00:15:46,840 --> 00:15:50,430 Por lo tanto, convertir un objeto JavaScript 217 00:15:50,430 --> 00:15:53,725 en notación JSON y viceversa es muy sencillo. 218 00:15:53,725 --> 00:15:57,420 La notación JSON es lo que llamamos como 219 00:15:57,420 --> 00:16:01,815 notación autodescriptiva y muy fácil de entender. 220 00:16:01,815 --> 00:16:05,103 En el formato de notación de objetos JavaScript, 221 00:16:05,103 --> 00:16:11,040 los datos se estructuran de una manera muy limpia y especificada. 222 00:16:11,040 --> 00:16:14,693 Esto está estructurado como una colección de nombres, pares de valores, 223 00:16:14,693 --> 00:16:19,610 y esto está estructurado como una lista ordenada de valores. 224 00:16:19,610 --> 00:16:23,375 Puede ver un ejemplo de esto en el lado derecho aquí. 225 00:16:23,375 --> 00:16:30,750 En realidad hemos utilizado estos datos JSON dentro de nuestra aplicación angular ya antes. 226 00:16:30,750 --> 00:16:35,570 Entonces, ahora ves por qué los datos están estructurados de esa manera. 227 00:16:35,570 --> 00:16:41,220 Y también te das cuenta de que es muy fácil poder tratar 228 00:16:41,220 --> 00:16:47,850 estos datos dentro de tu JavaScript o tu código TypeScript en tu aplicación Angular. 229 00:16:47,850 --> 00:16:55,000 Con esto, completo una breve descripción general de los elementos esenciales de la red.