Deixe-me começar por lhe dar
uma introdução rápida de 10 minutos ao Essentials of Networking.
Dado o fato de que temos tempo limitado,
eu me concentraria em fornecer
o essencial que você precisa para entender cada um dos tópicos.
Agora, o que abordamos neste módulo específico exigirá
pelo menos uma compreensão rudimentar de como
funciona a rede de computadores antes de entendermos por que precisamos usar HTTP,
por que nos comunicamos com um servidor,
qual é a razão para o atraso quando você está falando com um servidor e assim por diante.
Além disso, 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 introdução rápida de 10 minutos ao Essentials of Networking.
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 backend que suporta seu aplicativo web.
Hoje em dia, tudo está na Nuvem.
Muito em breve você estará na Nuvem também,
pelo menos na nuvem nove com um forro de prata.
Mas, dado que precisamos de
um suporte do lado do servidor para que nosso aplicativo angular funcione corretamente,
você hospedaria o servidor.
E hoje em dia, hospedar o servidor é muito
fácil 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 a servidores baseados em nuvem.
Então, o que exatamente está disponível no lado do servidor?
Normalmente, você tem um frontend de servidor que está falando com seu aplicativo angular, de
modo que é 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ê logo será bombardeado com 304 acrônimos pequenos,
coisas que você pensou saber o que eram do inglês normal ou que eles têm
um significado ou um
propósito completamente diferente quando você os encontra naquele mundo de rede.
Então vamos examinar alguns deles.
Então, no mundo da rede, você vai ouvir as pessoas falando sobre protocolo HTTP.
O protocolo que é usado para comunicação entre o cliente e o servidor.
Este é um protocolo de camada de aplicação
sobre o qual 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 dois pontos HTTP ou dois pontos HTTPS anexados na frente dele.
E tenho certeza que se você usou a World Wide Web,
você está bastante familiarizado com o que as URLs se parecem.
Agora, além disso, você ouviria as pessoas falando sobre JSON,
não seu amigo Jason, mas JavaScript Object Notation.
Portanto, a Notação de Objeto JavaScript é 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ê vai ouvir as pessoas falando sobre XML mais uma maneira de
codificar dados enquanto ele está em transporte entre o lado do cliente eo servidor.
Agora, também você vai ouvir as pessoas falando sobre protocolos de nível superior chamados SOAP,
não do tipo que você toma banho, mas SOAP como um protocolo que
permite a comunicação entre entidades de distribuição dentro de sua rede.
E também, você vai ouvir as pessoas falando sobre REST,
não algo que você recebe muito passando por este curso particular,
REST ou Transferência Estadual Representacional.
Terei uma palestra mais curta
especificamente dedicada ao REST um pouco mais tarde neste módulo.
E no mundo HTTP,
você ouvia as pessoas falando sobre GET, PUT
, POST e DELETE e você estaria se perguntando,
o que todas elas significam?
Vamos aprender um pouco sobre estes
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 site do cliente.
Então, o que significa que dentro do aplicativo do site do cliente,
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ê tenta se conectar a um servidor,
a conexão do servidor pode falhar,
o servidor pode retornar dados incorretos ou pode causar um erro na comunicação.
Todos eles devem ser tratados no lado do seu cliente adequadamente para que seu aplicativo
continue funcionando mesmo na presença desses problemas.
Saltando para o protocolo de camada de aplicativo mais popular
usado para comunicação entre o cliente e o servidor,
o Hypertext Transfer Protocol.
Mas este é um protocolo de comunicação do servidor cliente.
Agora que pode ou não fazer muito sentido para você a
menos que você tenha fundo suficiente em rede,
mas este é um protocolo que é usado para codificar as mensagens que você
trocou entre seu aplicativo cliente que é
um aplicativo angular neste caso e um lado do servidor.
Portanto, 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 suporte de várias ações HTTP ou o que chamamos de verbos HTTP,
HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS e CONNECT.
Veremos em particular os
verbos GET, PUT, POST e DELETE com mais detalhes quando examinarmos o protocolo REST API um pouco mais tarde.
Como funciona o protocolo HTTP?
No protocolo HTTP,
você está enviando solicitação GET 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 você deseja que o lado do servidor lhe envie.
E isso geralmente é uma mensagem GET se você quiser que
os dados sejam baixados do lado do servidor.
Você também especificará com qual servidor específico você está se comunicando.
Quando o servidor recebe sua solicitação,
o servidor recuperará os dados de seu armazenamento de dados,
geralmente um banco de dados no lado do servidor
e, em seguida, empacotará esses dados em
um formato apropriado e enviará os dados de volta para você no lado do cliente.
Se você estiver obtendo HTML padrão, CSS
e código JavaScript do lado do servidor,
então seu navegador é capaz de renderizar isso.
Mas com aplicativos como Angular,
você está se conectando principalmente ao servidor e, em seguida,
recuperando dados na forma de JSON ou XML a maior parte do tempo.
Exceto para o download inicial de todos os recursos necessários
para que seu aplicativo Angular seja executado dentro de seu navegador.
Então, como vimos anteriormente,
o aplicativo HTTP requer mensagens a serem enviadas entre o cliente e o servidor.
Normalmente, uma mensagem de solicitação é 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.
Veremos 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 o cliente estiver enviando dados para o lado do servidor.
Por exemplo, quando você envia um formulário,
as informações contidas no formulário são codificadas em
um formato JSON e, em seguida, enviadas para o lado do servidor a partir do lado do cliente.
Então isso será feito usando um POST ou uma mensagem PUT.
Olhando para o pouco mais 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, POST,
DELETE ou alguns dos outros verbos que você viu anteriormente
e, em seguida, seguido pela 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,
poderia ser codificado em formato JSON ou XML.
Aqui está um exemplo de
uma mensagem de solicitação HTTP típica que pode ser enviada para o servidor a partir do cliente.
Então, nesta mensagem de solicitação específica,
estamos pedindo ao servidor para reter a página index.html
do lado do servidor para o lado do cliente para que ele
possa ser processado no navegador no lado do cliente.
Uma solicitação como essa normalmente teria um corpo vazio na mensagem de solicitação.
A maioria das informações será codificada
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á uma resposta para o lado do cliente.
A mensagem de resposta é organizada novamente em três partes,
uma linha de status onde algumas informações sobre como
a solicitação foi processada e o que está sendo enviado de volta para o cliente é armazenado,
os cabeçalhos conterão detalhes adicionais do que está
contido na mensagem de resposta e, em seguida, seguido por uma linha em branco
e, em seguida, o corpo real da mensagem.
Um exemplo do que seria normalmente contido em uma mensagem de resposta HTTP,
neste caso, essa mensagem de resposta está voltando com um 200,
que é um código de status da mensagem.
Se você vir um 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 irá 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ê solicitou a página index.html,
o corpo da mensagem conterá o código HTML para
a página index.html como você vê neste exemplo aqui.
Uma das informações na linha de status a que me refiro como o código de status.
Se o servidor for capaz de processar sua solicitação corretamente,
ele enviará de volta uma resposta com um código de status 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 conseguir processar a solicitação por qualquer motivo
, essas informações serão codificadas
no código de status na linha de status da mensagem de resposta.
Os vários códigos de status normalmente que você encontrará quando você
recebe 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 foi movido permanentemente
para um novo local e a URL
do novo local desse recurso será retornada para o lado do cliente.
400s e 500s normalmente indicam que há algum problema no lado do servidor.
404 é algo que você encontra frequentemente quando
você solicita algo que não existe no lado do servidor.
Da mesma forma, 500 significa que o servidor está apenas desistindo,
não é capaz 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 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 vinda 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 Extended Markup Language ou JSON,
o formato JavaScript Object Notation.
Agora, tipicamente, neste curso particular,
estaremos lidando com dados que são codificados principalmente em JSON.
A maioria dos aplicativos do lado do cliente,
incluindo aplicativos móveis atualmente, normalmente se comunica 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 gastar alguns minutos explicando sobre JSON.
O JavaScript Object Notation 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,
mapeia facilmente em um objeto JavaScript que você usa com qualquer código JavaScript.
Portanto, converter um objeto JavaScript
em notação JSON e vice-versa é muito simples.
A notação JSON é o que chamamos de
auto-descrição e muito fácil de entender notação.
No formato JavaScript Object Notation,
os dados são estruturados de uma maneira muito limpa e especificada.
Isso é estruturado como uma coleção de nomes, pares de valores,
e isso é estruturado como uma lista ordenada de valores.
Você pode ver um exemplo disso no lado direito aqui.
Nós realmente usamos esses dados JSON dentro de 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 JavaScript ou seu código TypeScript em seu aplicativo Angular.
Com isso, concluo uma visão geral rápida dos fundamentos de rede.