Deixe-me começar dando a vocês uma rápida introdução
10 minutos ao essencial da rede.
Quanto mais eu ensino Inglês, mais eu percebo que apenas para usar suas características mais bonitas
de angular você precisa ter uma compreensão de tantas diferentes Fins conectados
antes de você pode sequer entender o que você está fazendo com angular.
No momento em que você começar a perseguir cada uma dessas Fins,
eles vão se tornar cursos inteiros por conta própria e muito em breve,
Eu vou acabar ensinando todo seu currículo de ciência da computação para você.
Mas dado o fato de que temos tempo limitado,
Eu vou me concentrar em entregar-lhe o essencial
que você precisa para entender cada um dos tópicos.
Agora, o que cobrimos neste módulo específico exigirá
pelo menos uma compreensão rudimentar de como a rede de computadores funciona
antes de entendermos por que precisamos usar HTTP,
por que nos comunicamos com um servidor.
Qual é a razão para o atraso é que quando você está falando com um servidor,
e assim por diante.
E também, os vários protocolos que você precisa estar ciente
antes mesmo de poder se comunicar com um servidor.
Então, tendo tudo isso em mente,
uma rápida introdução de 10 minutos ao essencial da rede.
Começamos a perceber que as aplicações web não são mais autônomas.
Eles sempre têm uma cotação unquote cloud back-end suportando sua aplicação web.
Agora, hoje em dia tudo está na Nuvem.
Em breve você estará na nuvem também, pelo menos na nuvem nove com um forro prateado.
Mas dado que precisamos de um suporte Silverside para que nosso aplicativo angular funcione corretamente,
lá você hospedaria o servidor.
E hoje em dia hospedar o servidor é muito facilmente feito usando um
dos serviços de infraestrutura baseados em nuvem.
Coisas como Amazon, Web Services ou Heroku ou Digital Ocean
ou muitos outros que fornecem suporte de servidor baseado em nuvem
que você pode aproveitar para fornecer suporte de servidor para seu aplicativo angular.
Então, no lado do servidor, o que exatamente está disponível no lado do servidor?
Normalmente, você tem um servidor front-end que está falando com seu aplicativo angular.
Então, essa é a lógica do servidor e nos bastidores,
a lógica do servidor está se comunicando com um armazenamento persistente como um banco de dados
onde seus dados são armazenados e recuperados.
Quando você entrar no mundo da rede, você será logo bombardeado
com 304 pequenos acrônimos.
Coisas que você pensou que sabia o que eram do inglês normal
ou eles têm um significado completamente diferente
ou propósito quando você os encontra no mundo da rede.
Então, vamos examinar alguns deles.
Então, no mundo da rede você ouvirá pessoas falando sobre o protocolo HTTP.
O protocolo usado para comunicação entre o cliente e o servidor.
Este é um protocolo de camada de aplicação
que falaremos brevemente um pouco mais no resto desta palestra.
O protocolo HTTP para que ele funcione precisa de um URL para ser fornecido a ele,
o Uniform Resource Locator.
Então, esta é uma cadeia de caracteres separados por barras com em cada dois-pontos TTP,
em um https: anexado na frente dele.
E eu tenho certeza que se você é usado a world wide web,
você está bastante familiarizado com a aparência dos URLs.
Agora, além disso, você vai ouvir as pessoas falando sobre JSON,
não para seu amigo Jason, mas JavaScript Object Notation.
Então, o JavaScript Object Notation é uma maneira de codificar dados que estão sendo enviados
do lado do servidor para o lado do cliente ou vice-versa.
E também, você ouvirá as pessoas falando sobre XML,
ainda outra maneira de codificar dados enquanto ele está em transporte de trânsito
entre o cliente e o site do servidor.
Agora, e também você vai ouvir as pessoas falando sobre protocolos de nível superior chamados SOAP,
não do tipo com que você toma banho, mas SOAP como um protocolo
que permite a comunicação entre entidades de distribuição dentro da rede.
E também, você vai ouvir as pessoas falando sobre REST, não algo
que você tem muito passando por este curso em particular.
REST ou uma Transferência de Estado Representacional.
Terei uma palestra mais curta especificamente dedicada
para REST um pouco mais tarde neste módulo.
E no mundo HTTP, você vai ouvir as pessoas falando sobre GET,
PUT, POST e DELETE, e você estaria se perguntando,
o que todos eles significam?
Vamos aprender um pouco sobre isso nesta palestra,
e também a palestra sobre REST que você verá um pouco mais tarde.
Uma coisa importante que você precisa entender quando você está se comunicando
com um servidor é que a comunicação do servidor cliente causa quantidade inesperada
de atrasos ou quantidade indeterminada de atraso
enquanto os dados estão sendo obtidos ou carregados para o servidor a partir do lado do cliente.
Então, o que significa que dentro de seu aplicativo cliente-servidor
você precisa manter o usuário informado sobre o fato
de que algo está acontecendo nos bastidores e ser capaz de lidar com os atrasos
e possivelmente não ser capaz de obter os dados do lado do servidor.
É bem possível que quando você tentou se conectar a um servidor,
a conexão com o servidor pode falhar,
o servidor pode retornar dados incorretos ou pode causar um erro na comunicação.
Todos estes têm de ser tratados do lado do cliente de forma adequada para
que o seu aplicativo ainda esteja funcionando mesmo na presença desses problemas.
Entrando no protocolo de camada de aplicativo mais popular usado para comunicar
entre o cliente e o servidor, o Hypertext Transfer Protocol
, mas este é um protocolo de comunicação de servidor cliente.
Agora, isso pode ou não fazer muito sentido para você
a menos que você tenha antecedentes suficientes em rede, mas este é um protocolo
que é usado para codificar as mensagens que você troca entre seu aplicativo cliente,
que é uma aplicação angular neste caso, e um lado do servidor.
Então, este protocolo HTTP permite que você recupere documentos baseados em hipertexto
do lado do servidor cada vez mais a informação que está sendo baixada
do lado do servidor é codificada em um dos formatos de codificação padrão como JSON ou XML.
E, para poder falar com um servidor,
você tem o apoio de várias ações HTTP,
ou o que chamamos de verbos HTTP: o HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS e CONNECT.
Veremos em particular os verbos GET, PUT, POST e DELETE em mais detalhes
quando examinarmos o protocolo API restante um pouco mais tarde.
Como funciona o protocolo HTTP?
No protocolo HTTP, você está enviando uma solicitação de seu aplicativo cliente para o servidor
e isso é codificado na forma de uma mensagem de solicitação HTTP.
A mensagem de solicitação normalmente carrega um URL na mensagem de solicitação indicando,
o que é que você deseja com o lado do servidor para enviar para você
e isso geralmente é uma mensagem GET
se você deseja que os dados sejam baixados do site do servidor.
E você também especificará com qual servidor específico você está se comunicando.
Quando o servidor recebe sua solicitação, o servidor irá
recuperar os dados de seu armazenamento de dados, normalmente um banco de dados no lado do servidor,
e, em seguida, empacotar esses dados em um apropriado quatro volta,
e enviar os dados de volta para você no lado do cliente.
Se você estiver obtendo código HTML, CSS e javascript padrão do lado do servidor,
então seu navegador é capaz de processar isso.
De volta com aplicativos como angular, você está se conectando principalmente ao servidor
e, em seguida, recuperando dados na forma de JSON ou XML na maioria das vezes.
Exceto para o download inicial de todos os recursos
necessários para que o aplicativo angular seja executado dentro do seu navegador.
Então, como vimos anteriormente, o aplicativo HTTP requer que mensagens sejam enviadas
entre o cliente e o servidor.
Uma mensagem de solicitação normalmente enviada do cliente para o servidor,
e a mensagem de solicitação consiste em uma linha de solicitação mais um monte de cabeçalhos
onde você fornece informações adicionais para qualificar a solicitação.
Vamos ver o uso de vários cabeçalhos
e configurações nos cabeçalhos à medida que passamos por alguns
dos exercícios neste módulo particular.
A linha de solicitação e os cabeçalhos são separados
do corpo da mensagem de solicitação por uma linha em branco.
O corpo da mensagem pode conter dados adicionais especialmente
se seus clientes estiverem enviando dados para o lado do servidor.
Por exemplo, quando você envia um formulário,
as informações dentro do formulário são codificadas para um formato JSON
e, em seguida, enviadas para o lado do servidor do lado do cliente.
Então, isso será feito usando um POST ou uma mensagem PUT.
Olhando para um pouco mais de detalhes da mensagem de solicitação HTTP,
a mensagem de solicitação típica na linha de solicitação conterá o Método,
que é GET, PUT, PAUSE, DELETE
ou alguns dos outros verbos que você já viu anteriormente.
E, em seguida, seguido pelo URL e a versão do protocolo HTTP
que você está usando para se comunicar do cliente para o lado do servidor.
O campo de cabeçalho geralmente contém um nome de campo de cabeçalho, dois pontos,
e o valor para esse campo de cabeçalho.
E o conteúdo do corpo, como mencionei, pode ser codificado em formato JSON ou XML.
Aqui está um exemplo de uma típica mensagem de solicitação HTTP
que pode ser enviada para o servidor a partir do cliente.
Então, nesta mensagem de solicitação particular, estamos pedindo ao servidor para reter
e index.hmtl página do lado do servidor para o lado do cliente para
que ele pode ser renderizado no navegador no lado do cliente.
Uma solicitação como esta normalmente teria um corpo vazio na mensagem de solicitação.
A maioria das informações serão codificadas na linha de solicitação mais os cabeçalhos
da mensagem de solicitação.
Quando o cliente envia a solicitação para o servidor,
o servidor processará a solicitação e, em seguida, enviará de volta uma resposta para o lado do cliente.
A mensagem de resposta está organizada em, novamente, três partes.
Uma linha de status com algumas informações sobre como a solicitação foi processada
e o que está sendo enviado de volta para o cliente é armazenada.
Os cabeçalhos conterão detalhes adicionais do que está contido na mensagem de resposta,
e seguidos por uma linha em branco e, em seguida, o corpo real da mensagem.
Um exemplo do que normalmente estaria contido em uma mensagem de resposta HTTP.
Neste caso, esta mensagem de resposta está voltando com um 200
que é um código de status da mensagem.
Se você vir aqui, 200 na linha de solicitação como um código de status.
Isso significa que sua solicitação foi bem-sucedida
e o servidor é capaz de retornar os dados que você solicitou do lado do servidor.
E, em seguida, o cabeçalho conterá direções adicionais para o lado do cliente,
incluindo informações sobre como o corpo real da mensagem é codificado.
Em seguida, o corpo pode conter, se você tiver solicitado a página HTML índice,
o corpo da mensagem conterá o código HTML
para a página HTML inicial do índice como você vê neste exemplo aqui.
Uma das informações na linha de status a que me refiro como esse código de status.
Se o servidor for capaz de processar seu pedido corretamente,
ele enviará de volta uma resposta com uma pontuação de estado de 200,
o que significa que tudo está bem no lado do servidor,
e o lado do servidor está retornando os dados corretamente.
Se o servidor não puder processar a solicitação por qualquer motivo,
então essa informação será codificada no código de status em
essa linha de status da mensagem de resposta.
Os vários códigos de status, normalmente, que você encontrará
quando você receber uma resposta do lado do servidor,
incluem um 201, o que significa que quando você tenta criar um objeto no lado do servidor,
ele foi criado com sucesso ou um 301 o que significa que o que você está solicitando
tem movido permanentemente para um novo local,
e que você está no novo local desse recurso
será devolvido ao lado do cliente.
400s e 500s normalmente indicam que existem alguns problemas no lado do servidor.
A 404 é algo que você costuma encontrar quando você solicita
para algo que não existe no lado do servidor.
Da mesma forma, um 500 significa que o servidor está apenas desistindo,
é incapaz de processar sua solicitação e, em seguida, envia de volta um erro interno do servidor.
Estes são dois códigos de erro comuns que você encontrará.
Os restantes têm um significado específico conforme listado nesta tabela aqui.
Há mais do que os códigos de status que eu lhe dei nesta tabela
, mas estes são alguns dos códigos de status mais comuns
que você encontrará em uma mensagem de resposta vindo do lado do servidor.
Outro ponto que mencionei é o fato de que o servidor pode codificar os dados
em um formato específico como XML ou eXtensible Markup Language ou JSON, o JavaScript
Object Notation para isso.
Agora, tipicamente neste curso em particular estaremos lidando com os dados
que são codificados principalmente em JSON.
A maioria dos aplicativos, aplicativos do lado do cliente incluindo aplicativos móveis atualmente,
geralmente se comunicam com o servidor
e o formato de troca de dados é JSON por padrão na maioria dos casos.
Essa é a razão pela qual vou passar alguns minutos explicando para você sobre JSON.
A notação de objeto javascript, ou JSON, é um formato leve de intercâmbio de dados.
A razão pela qual o formato de dados JSON é especificamente de interesse para nós neste curso é
porque a notação de objeto javascript, como o nome indica,
facilmente mapeia em um objeto javascript que você usa com qualquer um dos códigos javascript.
Então, converter um objeto javascript em notação JSON,
e vice-versa, é muito simples.
Essa notação JSON é uma, o que chamamos,
como uma notação auto-descritiva e muito fácil de entender.
No formato de notação de objeto javascript,
os dados são estruturados de uma maneira especificada muito limpa.
Esta é estruturada como uma coleção de pares nome/valor,
e esta é estruturada como uma lista ordenada de valores.
Você pode ver um exemplo disso no lado direito aqui,
nós realmente usamos esses dados JSON com nossa aplicação angular já anteriormente.
Então, agora você vê por que os dados são estruturados dessa maneira.
E você também percebe que é muito fácil ser capaz de lidar com esses dados
dentro de seu áudio javascript, typescript é pego em sua aplicação angular.
Com isso, concluo uma rápida visão geral dos essenciais de rede.
Agora vamos passar para e exercitar onde vamos configurar um servidor rudimentar
que foi servir alguns dados que podemos nos conectar a partir da nossa aplicação angular
e, em seguida, trocar dados com um servidor.
Agora, vamos desenvolver um servidor de pleno direito em um dos cursos posteriores,
o código de nó JS e curso de desenvolvimento do lado do servidor
que viria como um último curso nesta especialização.