Permítanme comenzar dándoles una rápida introducción
de 10 minutos a lo esencial de la creación de redes.
Cuanto más enseño inglés, más me doy cuenta de que solo para usar sus características más bonitas
de angular necesitas tener una comprensión de tantas diferentes aletas conectadas
antes de que puedas incluso entender lo que estás haciendo con angular.
En el momento en que empieces a perseguir a cada uno de estos FN,
se convertirán en cursos completos por su cuenta y muy pronto,
terminaré enseñándote todo su currículo de ciencias de la computación.
Pero dado el hecho de que tenemos tiempo limitado,
me concentraré en entregarles lo esencial
que necesitan para entender 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 de computadoras
antes de entender por qué necesitamos usar HTTP,
por qué nos comunicamos con un servidor.
Cuál es la razón del retraso es que cuando estás hablando con un servidor,
y así sucesivamente.
Y también, los diversos protocolos que usted necesita tener en cuenta
antes de que incluso pueda comunicarse con un servidor.
Así que, teniendo todo esto en mente,
una introducción rápida de 10 minutos a lo esencial de la creación de redes.
Comenzamos a darnos cuenta de que las aplicaciones web ya no son independientes.
Siempre tienen un back-end de nube comillas que apoya 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 nueve con un forro plateado.
Pero dado que necesitamos un soporte de Silverside para que nuestra aplicación angular funcione correctamente,
allí alojaría el servidor.
Y en estos días alojar el servidor se hace muy fácilmente mediante el uso de uno
de los servicios de infraestructura basados en la nube.
Cosas como Amazon, Web Services o Heroku o Digital Ocean
o muchos otros que proporcionan soporte de servidor basado en la nube
que puede aprovechar para proporcionar soporte de servidor para su aplicación angular.
Entonces, en el lado del servidor, ¿qué está exactamente disponible en el lado del servidor?
Normalmente tiene un servidor front-end que está hablando con su aplicación angular.
Entonces, esa es la lógica del servidor y detrás de escena,
la lógica del servidor se está comunicando con un almacenamiento persistente como una base de datos
donde se almacenan y recuperan sus datos.
Cuando entres en el mundo de las redes, pronto serás bombardeado
con 304 pequeños acrónimos.
Cosas que pensaste que sabías lo que eran del inglés normal
o que tienen un significado totalmente diferente
o propósito cuando las encuentras en el mundo de las redes.
Por lo tanto, examinemos algunos de ellos.
Por lo tanto, en el mundo de las redes oirás a la gente hablar 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 URL que se le proporcione,
el Localizador de Recursos Uniforme.
Entonces, esta es una cadena de caracteres separados por barras diagonales con en cada dos puntos TTP,
en un https: adjunto delante de él.
Y estoy seguro de que si se usa la World Wide Web,
está bastante familiarizado con cómo se ven las URL.
Ahora, además, escucharás a la gente hablando de JSON,
no a tu amigo Jason, sino JavaScript Object Notation.
Por lo tanto, la notación de objetos JavaScript es una forma de codificar datos que se envían
desde el lado del servidor al lado del cliente o viceversa.
Y también, oirá a la gente hablar de XML,
otra forma de codificar datos mientras está en tránsito el envío
entre el cliente y el sitio del servidor.
Ahora, y también escucharán a la gente hablar de protocolos de alto nivel 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 la red.
Y también, oirás a la gente hablar de REST, no de algo
que obtienes demasiado pasando por este curso en particular.
REST o una Transferencia de Estado 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ás a la gente hablar de GET,
PUT, POST y DELETE, y te preguntarías,
¿qué significan todos?
Vamos a aprender un poco sobre esto en esta conferencia,
y también la conferencia sobre REST que verá un poco más tarde.
Una cosa importante que debes entender cuando te estás comunicando
con un servidor es que la comunicación del servidor cliente provoca una cantidad inesperada
de retrasos o una cantidad indeterminada de retraso
mientras los datos se están recuperando o cargando en el servidor desde el lado del cliente.
Entonces, lo que significa que dentro de su aplicación cliente-servidor
necesita mantener informado al usuario sobre el hecho
de que algo está pasando detrás de las escenas y ser capaz de manejar los retrasos
y posiblemente no ser capaz de obtener los datos del lado del servidor.
Es muy posible que cuando intenta conectarse a un servidor,
la conexión con el servidor puede fallar,
el servidor puede devolver datos incorrectos o puede causar un error en la comunicación.
Todos estos tienen que ser manejados en su lado del cliente de manera adecuada para
que su aplicación siga funcionando incluso en presencia de estos problemas.
Saltando en el 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 de servidor cliente.
Ahora, eso puede o no tener mucho sentido para ti
a menos que tengas suficiente experiencia en redes, pero este es un protocolo
que se usa para codificar los mensajes que intercambias entre tu 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,
tienes 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 resto del protocolo API un poco más tarde.
¿Cómo funciona el protocolo HTTP?
En el protocolo HTTP, está enviando una solicitud desde su aplicación cliente al servidor
y esto está codificado en la forma de un mensaje de solicitud HTTP.
El mensaje de solicitud normalmente lleva una URL en el mensaje de solicitud indicando,
qué es lo que desea que con el lado del servidor le envíe
y esto es normalmente un mensaje GET
si desea que los datos se descarguen del sitio del servidor.
Y también especificará con qué servidor particular 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 apropiado cuatro atrás,
y le enviará los datos de vuelta en su lado del cliente.
Si está obteniendo código estándar HTML, CSS y javascript desde el lado del servidor,
entonces su navegador puede renderizar esto.
De vuelta con aplicaciones como angular, se está conectando principalmente 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 la aplicación angular se ejecute dentro de su navegador.
Por lo tanto, como vimos anteriormente, la aplicación HTTP requiere que se envíen mensajes
entre el cliente y el servidor.
Un mensaje de solicitud normalmente enviado desde el cliente al servidor,
y el mensaje de solicitud consiste en 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 vamos a través de algunos
de los ejercicios en 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 sus clientes están enviando datos al lado del servidor.
Por ejemplo, cuando envía un formulario,
la información dentro del formulario se codifica a un formato JSON
y luego se envía al lado del servidor desde el lado del cliente.
Entonces, eso se hará usando un mensaje POST o PUT.
Mirando un poco más de 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, PAUSE, DELETE
o algunos de los otros verbos que ha visto anteriormente.
Y luego, seguido de la URL y la versión del protocolo HTTP
que está utilizando para comunicarse desde el cliente al servidor.
El campo de encabezado suele contener 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.
Por lo tanto, en este mensaje de solicitud en particular, estamos pidiendo al servidor que conserve la página
e index.hmtl desde el lado del servidor al lado del cliente para
que se pueda representar 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 está organizado en, de nuevo, tres partes.
Se almacena una línea de estado con cierta información sobre cómo se ha procesado la solicitud
y qué 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 vuelve con un 200
que es un código de estado del mensaje.
Si ves aquí, 200 en la línea de solicitud como código de estado.
Significa que su solicitud fue exitosa
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 HTML del índice,
el cuerpo del mensaje contendrá el código HTML
para la página HTML de inicio del índice 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 ese código de estado.
Si el servidor es capaz de procesar su solicitud correctamente,
enviará una respuesta con una puntuación 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,
entonces esa información se codificará en el código de estado en
esa línea de estado del mensaje de respuesta.
Los diversos códigos de estado, típicamente, que encontrará
cuando reciba 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
tiene movido permanentemente a una nueva ubicación,
y que se encuentra en la nueva ubicación de ese recurso
será devuelto a su lado cliente.
400 y 500 típicamente indican que hay algunos problemas en el lado del servidor.
Un 404 es algo que a menudo se encuentra cuando solicita
para algo que no existe en el lado del servidor.
Del mismo modo, un 500 significa que el servidor está renunciando,
no puede procesar su solicitud y luego envía un error interno del servidor.
Estos son dos códigos de error comunes que encontrará.
Los restantes tienen un significado específico como se enumeran en esta tabla aquí.
Hay más que los códigos de estado que te di en esta tabla
, pero estos son algunos de los códigos de estado más comunes
que encontrarás en un mensaje de respuesta procedente 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 Extensible Markup Language o JSON, el JavaScript
Object Notation para eso.
Ahora, normalmente en este curso en particular vamos a tratar con los datos
que están codificados principalmente en JSON.
La mayoría de las aplicaciones, aplicaciones del lado del cliente incluyendo aplicaciones móviles en estos días,
normalmente se comunican con el servidor
y el formato de intercambio de datos es JSON por defecto en la mayoría de los casos.
Esa es la razón por la que pasaré unos minutos explicándote sobre JSON.
La notación de objeto 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 se utiliza con cualquiera de los códigos javascript.
Entonces, convertir un objeto javascript en notación JSON,
y viceversa, es muy sencillo.
Esa notación JSON es una, lo que llamamos,
como una notación autodescriptiva y muy fácil de entender.
En el formato de notación de objeto javascript,
los datos se estructuran de una manera especificada muy limpia.
Esto se estructura como una colección de pares nombre/valor,
y esto se estructura como una lista ordenada de valores.
Puede ver un ejemplo de esto en el lado derecho aquí,
en realidad hemos utilizado estos datos JSON con 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 lidiar con estos datos
dentro de tu audio javascript, la mecanografía está atrapada en tu aplicación angular.
Con esto completaré una breve descripción de los elementos esenciales de la red.
Ahora vamos a pasar y hacer ejercicio donde vamos a configurar un servidor rudimentario
que fue servir algunos datos a los que podemos conectar desde nuestra aplicación angular
y luego intercambiar datos con un servidor.
Ahora, vamos a desarrollar un servidor completo en uno de los cursos posteriores,
el código de nodo JS y el curso de desarrollo del lado del servidor
que vendría como un último curso en esta especialización.