Permítanme comenzar dándoles
una introducción rápida de 10 minutos a lo esencial de las redes.
Dado el hecho de que tenemos un tiempo limitado,
me concentraría en entregarle
lo esencial que necesita para comprender cada uno de los temas.
Ahora, lo que cubrimos en este módulo en particular requerirá
al menos una comprensión rudimentaria de cómo
funciona la red informática antes de entender por
qué necesitamos usar HTTP, por qué nos comunicamos con un servidor,
cuál es la razón del retraso cuando se habla con un servidor, etc.
Y también, los diversos protocolos que
debe tener en cuenta antes de que pueda comunicarse con un servidor.
Por lo tanto, teniendo todo esto en cuenta,
una rápida introducción de 10 minutos a los Essentials of Networking.
Comenzamos a darnos cuenta de que las aplicaciones web ya no son independientes.
Siempre tienen un backend de la nube sin comillas que respalda su aplicación web.
Ahora, en estos días, todo está en la Nube.
Muy pronto estarás en la Nube también,
al menos en la Nube 9 con un forro plateado.
Pero, dado que necesitamos
un soporte del lado del servidor para que nuestra aplicación angular funcione correctamente,
allí alojaría el servidor.
Y en la actualidad, el alojamiento del servidor se
realiza muy fácilmente utilizando uno de los servicios de infraestructura basados en la nube,
elementos como Amazon Web Services o Heroku u u Digital
Ocean, u otros muchos que proporcionan soporte de servidor basado en la nube.
Entonces, ¿qué está disponible exactamente en el lado del servidor?
Por lo general, tiene un frontend de servidor que está hablando con su aplicación angular,
por lo que esa es la lógica del servidor y detrás de las escenas la lógica del servidor se comunica con
un almacenamiento persistente como una base de datos donde se almacenan y recuperan sus datos.
Cuando entras en el mundo de las redes,
pronto serás bombardeado con 304 pequeños acrónimos,
cosas que pensabas que sabías lo que eran del inglés normal o que tienen
un significado o
propósito completamente diferente cuando te encuentras con ellos en ese mundo de las redes.
Así que vamos a examinar algunos de ellos.
Entonces, en el mundo de las redes, escuchará a la gente hablando a través del protocolo HTTP.
El protocolo que se utiliza para la comunicación entre el cliente y el servidor.
Este es un protocolo de capa de aplicación del que
hablaremos brevemente un poco más en el resto de esta conferencia.
El protocolo HTTP para que funcione necesita una dirección URL que se le proporcione,
el Localizador uniforme de recursos.
Así que esta es una cadena de caracteres separados por barras diagonales,
con dos puntos HTTP o dos puntos HTTPS adjuntos delante de ella.
Y estoy seguro de que si ha utilizado la World Wide Web,
está bastante familiarizado con el aspecto de las URL.
Ahora, además, oirías a la gente hablando de JSON,
no de tu amigo Jason, sino de JavaScript Object Notation.
Por lo tanto, la notación de objetos JavaScript es una forma de codificar los datos que
se envían desde el lado del servidor al lado del cliente o viceversa.
Y también escuchará a la gente hablando de XML otra forma de
codificar datos mientras está en tránsito entre el lado del cliente y el servidor.
Ahora, también escuchará a la gente hablando de protocolos de nivel superior llamados SOAP,
no del tipo con el que se toma una ducha, sino SOAP como un protocolo que
permite la comunicación entre entidades de distribución dentro de su red.
Y también, usted escuchará a la gente hablando de REST,
no algo que se obtiene demasiado pasando por este curso en particular,
REST o Transferencia Estatal Representacional.
Tendré una conferencia más corta
dedicada específicamente a REST un poco más adelante en este módulo.
Y en el mundo HTTP,
oirías a la gente hablando de GET,
PUT, POST y DELETE y te preguntarías,
¿qué significan todos ellos?
Vamos a aprender un poco sobre estos en
esta conferencia y también la conferencia sobre REST que verá un poco más tarde.
Una cosa importante que debe comprender cuando se está
comunicando con un servidor es que la comunicación del servidor cliente
causa una cantidad inesperada de retrasos o una cantidad indeterminada de retardo
mientras los datos se están recuperando o cargando en el servidor desde el sitio del cliente.
Lo que significa que dentro de su aplicación de sitio cliente,
debe mantener al usuario informado sobre el hecho de que
algo está sucediendo entre bastidores y ser
capaz de manejar los retrasos y
posiblemente no ser capaz de obtener los datos desde el lado del servidor.
Es muy posible que cuando intenta conectarse a un servidor,
la conexión del servidor puede fallar,
el servidor puede devolver datos incorrectos o puede causar un error en la comunicación.
Todo esto tiene que ser manejado en el lado del cliente de manera adecuada para que su aplicación
siga funcionando incluso en presencia de estos problemas.
Saltar al protocolo de capa de aplicación más popular
utilizado para la comunicación entre el cliente y el servidor,
el Protocolo de transferencia de hipertexto.
Pero este es un protocolo de comunicación cliente servidor.
Ahora eso puede o no tener mucho sentido para usted a
menos que tenga suficiente experiencia en redes,
pero este es un protocolo que se usa para codificar los mensajes que
intercambió entre su aplicación cliente, que es
una aplicación angular en este caso y un lado del servidor.
Por lo tanto, este protocolo HTTP le permite
recuperar documentos basados en hipertexto desde el lado del servidor,
cada vez más la información que se descarga desde el lado del servidor está
codificada en uno de los formatos de codificación estándar como JSON o XML.
Y para poder hablar con un servidor,
usted tiene el apoyo de varias acciones HTTP o lo que nos referimos como verbos HTTP,
HEAD, GET, POST, PUT,
DELETE, TRACE, OPTIONS y CONNECT.
Veremos en particular los
verbos GET, PUT, POST y DELETE con más detalle cuando examinemos el protocolo REST API un poco más tarde.
¿ Cómo funciona el protocolo HTTP?
En el protocolo HTTP,
está enviando solicitud GET desde su aplicación cliente al servidor.
Y esto está codificado en forma de un mensaje de solicitud HTTP.
El mensaje de solicitud suele incluir una URL en
el mensaje de solicitud que indica qué es lo que desea que le envíe el lado del servidor.
Y este es típicamente un mensaje GET si desea que
los datos se descarguen desde el lado del servidor.
También especificará con qué servidor concreto se está comunicando.
Cuando el servidor recibe su solicitud,
el servidor recuperará los datos de su almacenamiento de datos,
normalmente una base de datos en el lado del servidor,
y luego empaquetará estos datos en
un formato adecuado y le enviará los datos en el lado del cliente.
Si está obteniendo
código HTML estándar, CSS y JavaScript desde el lado del servidor,
entonces su navegador puede renderizar esto.
Pero con aplicaciones como Angular,
principalmente se está conectando al servidor y luego
recuperando datos en forma de JSON o XML la mayor parte del tiempo.
Excepto por la descarga inicial de todos los recursos necesarios
para que su aplicación Angular se ejecute dentro de su navegador.
Como vimos anteriormente,
la aplicación HTTP requiere que se envíen mensajes entre el cliente y el servidor.
Normalmente, un mensaje de solicitud se envía desde el cliente al servidor y
el mensaje de solicitud consta de una línea de solicitud más un montón de encabezados,
donde se proporciona información adicional para calificar la solicitud.
Veremos el uso de varios encabezados y ajustes en
los encabezados a medida que pasamos por algunos de los ejercicios de este módulo en particular.
La línea de solicitud y los encabezados están separados del cuerpo
del mensaje de solicitud por una línea en blanco.
El cuerpo del mensaje puede contener datos adicionales,
especialmente si su cliente envía datos al lado del servidor.
Por ejemplo, cuando envía un formulario,
la información dentro del formulario se codifica en
un formato JSON y, a continuación, se envía al lado del servidor desde el lado del cliente.
Así que eso se hará usando un mensaje POST o PUT.
Mirando los pequeños detalles del mensaje de solicitud HTTP,
el mensaje de solicitud típico en
la línea de solicitud contendrá el método que es GET, PUT, POST,
DELETE o algunos de los otros verbos que ha visto anteriormente,
y luego seguido por la URL y la versión
del Protocolo HTTP que está utilizando para comunicarse desde el cliente al lado del servidor.
El campo de encabezado generalmente contiene un nombre de campo de encabezado,
dos puntos y el valor de ese campo de encabezado.
Y el contenido del cuerpo, como mencioné,
podría codificarse en formato JSON o XML.
Aquí hay un ejemplo de
un mensaje de solicitud HTTP típico que se puede enviar al servidor desde el cliente.
Entonces, en este mensaje de solicitud en particular,
estamos pidiendo al servidor que retenga la página index.html desde
el lado del servidor hasta el lado del cliente para que
se pueda renderizar en el navegador en el lado del cliente.
Una solicitud como esta normalmente tendría un cuerpo vacío en el mensaje de solicitud.
La mayor parte de la información se codificará en
la línea de solicitud más los encabezados del mensaje de solicitud.
Cuando el cliente envía la solicitud al servidor.
El servidor procesará la solicitud y luego enviará una respuesta al lado del cliente.
El mensaje de respuesta se organiza de nuevo en tres partes,
una línea de estado donde se
almacena información sobre cómo se ha procesado la solicitud y lo que se está enviando al cliente,
los encabezados contendrán detalles adicionales de lo que está
contenido en el mensaje de respuesta y luego seguido de una línea en blanco
y, a continuación, el cuerpo real del mensaje.
Un ejemplo de lo que normalmente estaría contenido en un mensaje de respuesta HTTP,
en este caso, este mensaje de respuesta regresa con un 200,
que es un código de estado del mensaje.
Si ve un 200 en la línea de solicitud como código de estado,
significa que su solicitud se realizó correctamente y el servidor puede
devolver los datos que ha solicitado desde el lado del servidor.
Y luego el encabezado contendrá instrucciones adicionales al
lado del cliente, incluyendo información sobre
cómo se codifica el cuerpo real del mensaje.
A continuación, el cuerpo puede contener,
si ha solicitado la página index.html,
el cuerpo del mensaje contendrá el código HTML de
la página index.html como se ve en este ejemplo aquí.
Una de las piezas de información en la línea de estado a la que me refiero como el código de estado.
Si el servidor puede procesar su solicitud correctamente,
enviará una respuesta con un código de estado de 200, lo que
significa que todo está bien en el lado del servidor y
el lado del servidor devuelve los datos correctamente.
Si el servidor no puede procesar la solicitud por cualquier motivo,
esa información se codificará en
el código de estado en la línea de estado del mensaje de respuesta.
Los diversos códigos de estado que normalmente encontrará cuando
recibe una respuesta del lado del servidor incluyen un 201,
lo que significa que cuando intenta crear
un objeto en el lado del servidor se ha creado con éxito,
o un 301, lo que significa que lo que está solicitando se ha movido permanentemente
a una nueva ubicación y la URL de
la nueva ubicación de ese recurso se devolverá al lado del cliente.
400 y 500 por lo general indican que hay algún problema en el lado del servidor.
404 es algo que a menudo
encuentras cuando solicitas algo que no existe en el lado del servidor.
Del mismo modo, 500 significa que el servidor simplemente se da por vencido,
no puede procesar su solicitud y luego envía de vuelta un error interno del servidor.
Estos son dos códigos de error comunes que encontrará.
Los restantes tienen un significado específico como se indica en esta tabla.
Hay más que los códigos de estado que le di en esta tabla,
pero estos son algunos de los códigos de estado más comunes que
encontrará en un mensaje de respuesta proveniente del lado del servidor.
Otro punto que mencioné es el hecho de que el servidor puede codificar
los datos en un formato específico como XML o Lenguaje de marcado extendido o JSON,
el formato de notación de objetos JavaScript.
Ahora típicamente, en este curso en particular,
trataremos con datos que están codificados principalmente en JSON.
La mayoría de las aplicaciones del lado del cliente
, incluidas las aplicaciones móviles, normalmente se comunican con
el servidor y el formato de intercambio de datos es JSON de forma predeterminada en la mayoría de los casos.
Esa es la razón por la que voy a pasar unos minutos explicándole sobre JSON.
La notación de objetos JavaScript o JSON es un formato de intercambio de datos ligero.
La razón por la que el formato de datos JSON es específicamente de
interés para nosotros en este curso es porque la notación de objetos JavaScript,
como su nombre lo indica,
se asigna muy fácilmente a un objeto JavaScript que usa con cualquier código JavaScript.
Por lo tanto, convertir un objeto JavaScript
en notación JSON y viceversa es muy sencillo.
La notación JSON es lo que llamamos como
notación autodescriptiva y muy fácil de entender.
En el formato de notación de objetos JavaScript,
los datos se estructuran de una manera muy limpia y especificada.
Esto está estructurado como una colección de nombres, pares de valores,
y esto está estructurado como una lista ordenada de valores.
Puede ver un ejemplo de esto en el lado derecho aquí.
En realidad hemos utilizado estos datos JSON dentro de nuestra aplicación angular ya antes.
Entonces, ahora ves por qué los datos están estructurados de esa manera.
Y también te das cuenta de que es muy fácil poder tratar
estos datos dentro de tu JavaScript o tu código TypeScript en tu aplicación Angular.
Con esto, completo una breve descripción general de los elementos esenciales de la red.