1 00:00:03,880 --> 00:00:06,815 Deixe-me começar por lhe dar 2 00:00:06,815 --> 00:00:11,165 uma introdução rápida de 10 minutos ao Essentials of Networking. 3 00:00:11,165 --> 00:00:14,045 Dado o fato de que temos tempo limitado, 4 00:00:14,045 --> 00:00:16,355 eu me concentraria em fornecer 5 00:00:16,355 --> 00:00:21,191 o essencial que você precisa para entender cada um dos tópicos. 6 00:00:21,191 --> 00:00:26,240 Agora, o que abordamos neste módulo específico exigirá 7 00:00:26,240 --> 00:00:30,230 pelo menos uma compreensão rudimentar de como 8 00:00:30,230 --> 00:00:34,255 funciona a rede de computadores antes de entendermos por que precisamos usar HTTP, 9 00:00:34,255 --> 00:00:36,700 por que nos comunicamos com um servidor, 10 00:00:36,700 --> 00:00:42,485 qual é a razão para o atraso quando você está falando com um servidor e assim por diante. 11 00:00:42,485 --> 00:00:45,920 Além disso, os vários protocolos que você 12 00:00:45,920 --> 00:00:50,335 precisa estar ciente antes mesmo de poder se comunicar com um servidor. 13 00:00:50,335 --> 00:00:53,540 Então, tendo tudo isso em mente, 14 00:00:53,540 --> 00:00:58,945 uma introdução rápida de 10 minutos ao Essentials of Networking. 15 00:00:58,945 --> 00:01:03,600 Começamos a perceber que as aplicações web não são mais autônomas. 16 00:01:03,600 --> 00:01:11,030 Eles sempre têm uma cotação unquote Cloud backend que suporta seu aplicativo web. 17 00:01:11,030 --> 00:01:13,535 Hoje em dia, tudo está na Nuvem. 18 00:01:13,535 --> 00:01:15,500 Muito em breve você estará na Nuvem também, 19 00:01:15,500 --> 00:01:19,455 pelo menos na nuvem nove com um forro de prata. 20 00:01:19,455 --> 00:01:23,785 Mas, dado que precisamos de 21 00:01:23,785 --> 00:01:29,090 um suporte do lado do servidor para que nosso aplicativo angular funcione corretamente, 22 00:01:29,090 --> 00:01:31,295 você hospedaria o servidor. 23 00:01:31,295 --> 00:01:36,405 E hoje em dia, hospedar o servidor é muito 24 00:01:36,405 --> 00:01:42,575 fácil usando um dos serviços de infraestrutura baseados em nuvem, 25 00:01:42,575 --> 00:01:48,260 coisas como Amazon Web Services ou Heroku ou Digital 26 00:01:48,260 --> 00:01:55,190 Ocean ou muitos outros que fornecem suporte a servidores baseados em nuvem. 27 00:01:55,190 --> 00:01:59,235 Então, o que exatamente está disponível no lado do servidor? 28 00:01:59,235 --> 00:02:06,744 Normalmente, você tem um frontend de servidor que está falando com seu aplicativo angular, de 29 00:02:06,744 --> 00:02:14,615 modo que é a lógica do servidor e, nos bastidores, a lógica do servidor está se comunicando com 30 00:02:14,615 --> 00:02:23,665 um armazenamento persistente, como um banco de dados onde seus dados são armazenados e recuperados. 31 00:02:23,665 --> 00:02:26,130 Quando você entrar no mundo da rede, 32 00:02:26,130 --> 00:02:31,064 você logo será bombardeado com 304 acrônimos pequenos, 33 00:02:31,064 --> 00:02:36,230 coisas que você pensou saber o que eram do inglês normal ou que eles têm 34 00:02:36,230 --> 00:02:38,360 um significado ou um 35 00:02:38,360 --> 00:02:42,375 propósito completamente diferente quando você os encontra naquele mundo de rede. 36 00:02:42,375 --> 00:02:44,470 Então vamos examinar alguns deles. 37 00:02:44,470 --> 00:02:49,020 Então, no mundo da rede, você vai ouvir as pessoas falando sobre protocolo HTTP. 38 00:02:49,020 --> 00:02:53,215 O protocolo que é usado para comunicação entre o cliente e o servidor. 39 00:02:53,215 --> 00:02:56,960 Este é um protocolo de camada de aplicação 40 00:02:56,960 --> 00:03:01,135 sobre o qual falaremos brevemente um pouco mais no resto desta palestra. 41 00:03:01,135 --> 00:03:07,550 O protocolo HTTP para que ele funcione precisa de um URL para ser fornecido a ele, 42 00:03:07,550 --> 00:03:09,715 o Uniform Resource Locator. 43 00:03:09,715 --> 00:03:15,205 Então esta é uma cadeia de caracteres separados por barras, 44 00:03:15,205 --> 00:03:22,355 com dois pontos HTTP ou dois pontos HTTPS anexados na frente dele. 45 00:03:22,355 --> 00:03:25,547 E tenho certeza que se você usou a World Wide Web, 46 00:03:25,547 --> 00:03:29,395 você está bastante familiarizado com o que as URLs se parecem. 47 00:03:29,395 --> 00:03:33,230 Agora, além disso, você ouviria as pessoas falando sobre JSON, 48 00:03:33,230 --> 00:03:38,380 não seu amigo Jason, mas JavaScript Object Notation. 49 00:03:38,380 --> 00:03:43,610 Portanto, a Notação de Objeto JavaScript é uma maneira de codificar dados que 50 00:03:43,610 --> 00:03:49,660 estão sendo enviados do lado do servidor para o lado do cliente ou vice-versa. 51 00:03:49,660 --> 00:03:54,320 E também você vai ouvir as pessoas falando sobre XML mais uma maneira de 52 00:03:54,320 --> 00:04:01,205 codificar dados enquanto ele está em transporte entre o lado do cliente eo servidor. 53 00:04:01,205 --> 00:04:08,375 Agora, também você vai ouvir as pessoas falando sobre protocolos de nível superior chamados SOAP, 54 00:04:08,375 --> 00:04:14,045 não do tipo que você toma banho, mas SOAP como um protocolo que 55 00:04:14,045 --> 00:04:21,975 permite a comunicação entre entidades de distribuição dentro de sua rede. 56 00:04:21,975 --> 00:04:25,295 E também, você vai ouvir as pessoas falando sobre REST, 57 00:04:25,295 --> 00:04:29,505 não algo que você recebe muito passando por este curso particular, 58 00:04:29,505 --> 00:04:32,510 REST ou Transferência Estadual Representacional. 59 00:04:32,510 --> 00:04:36,200 Terei uma palestra mais curta 60 00:04:36,200 --> 00:04:40,970 especificamente dedicada ao REST um pouco mais tarde neste módulo. 61 00:04:40,970 --> 00:04:42,905 E no mundo HTTP, 62 00:04:42,905 --> 00:04:45,990 você ouvia as pessoas falando sobre GET, PUT 63 00:04:45,990 --> 00:04:50,210 , POST e DELETE e você estaria se perguntando, 64 00:04:50,210 --> 00:04:52,200 o que todas elas significam? 65 00:04:52,200 --> 00:04:55,250 Vamos aprender um pouco sobre estes 66 00:04:55,250 --> 00:05:01,245 nesta palestra e também a palestra sobre REST que você verá um pouco mais tarde. 67 00:05:01,245 --> 00:05:05,020 Uma coisa importante que você precisa entender quando você está 68 00:05:05,020 --> 00:05:10,120 se comunicando com um servidor é que a comunicação do servidor cliente 69 00:05:10,120 --> 00:05:15,130 causa quantidade inesperada de atrasos ou quantidade indeterminada de atraso 70 00:05:15,130 --> 00:05:21,340 enquanto os dados estão sendo obtidos ou carregados para o servidor a partir do site do cliente. 71 00:05:21,340 --> 00:05:23,270 Então, o que significa que dentro do aplicativo do site do cliente, 72 00:05:23,270 --> 00:05:27,310 você precisa manter o usuário informado sobre o fato de que 73 00:05:27,310 --> 00:05:31,750 algo está acontecendo nos bastidores e ser 74 00:05:31,750 --> 00:05:35,335 capaz de lidar com os atrasos e 75 00:05:35,335 --> 00:05:41,020 possivelmente não ser capaz de obter os dados do lado do servidor. 76 00:05:41,020 --> 00:05:45,490 É bem possível que quando você tenta se conectar a um servidor, 77 00:05:45,490 --> 00:05:47,765 a conexão do servidor pode falhar, 78 00:05:47,765 --> 00:05:53,920 o servidor pode retornar dados incorretos ou pode causar um erro na comunicação. 79 00:05:53,920 --> 00:05:58,750 Todos eles devem ser tratados no lado do seu cliente adequadamente para que seu aplicativo 80 00:05:58,750 --> 00:06:04,450 continue funcionando mesmo na presença desses problemas. 81 00:06:04,450 --> 00:06:09,250 Saltando para o protocolo de camada de aplicativo mais popular 82 00:06:09,250 --> 00:06:12,880 usado para comunicação entre o cliente e o servidor, 83 00:06:12,880 --> 00:06:15,405 o Hypertext Transfer Protocol. 84 00:06:15,405 --> 00:06:18,585 Mas este é um protocolo de comunicação do servidor cliente. 85 00:06:18,585 --> 00:06:20,800 Agora que pode ou não fazer muito sentido para você a 86 00:06:20,800 --> 00:06:23,532 menos que você tenha fundo suficiente em rede, 87 00:06:23,532 --> 00:06:28,480 mas este é um protocolo que é usado para codificar as mensagens que você 88 00:06:28,480 --> 00:06:31,330 trocou entre seu aplicativo cliente que é 89 00:06:31,330 --> 00:06:35,375 um aplicativo angular neste caso e um lado do servidor. 90 00:06:35,375 --> 00:06:38,620 Portanto, este protocolo HTTP permite que você 91 00:06:38,620 --> 00:06:42,450 recupere documentos baseados em hipertexto do lado do servidor, 92 00:06:42,450 --> 00:06:47,200 cada vez mais a informação que está sendo baixada do lado do servidor é 93 00:06:47,200 --> 00:06:52,495 codificada em um dos formatos de codificação padrão como JSON ou XML. 94 00:06:52,495 --> 00:06:55,750 E para poder falar com um servidor, 95 00:06:55,750 --> 00:07:04,180 você tem o suporte de várias ações HTTP ou o que chamamos de verbos HTTP, 96 00:07:04,180 --> 00:07:07,135 HEAD, GET, POST, 97 00:07:07,135 --> 00:07:11,020 PUT, DELETE, TRACE, OPTIONS e CONNECT. 98 00:07:11,020 --> 00:07:14,080 Veremos em particular os 99 00:07:14,080 --> 00:07:24,395 verbos GET, PUT, POST e DELETE com mais detalhes quando examinarmos o protocolo REST API um pouco mais tarde. 100 00:07:24,395 --> 00:07:27,670 Como funciona o protocolo HTTP? 101 00:07:27,670 --> 00:07:30,010 No protocolo HTTP, 102 00:07:30,010 --> 00:07:35,215 você está enviando solicitação GET de seu aplicativo cliente para o servidor. 103 00:07:35,215 --> 00:07:39,780 E isso é codificado na forma de uma mensagem de solicitação HTTP. 104 00:07:39,780 --> 00:07:43,760 A mensagem de solicitação normalmente carrega um URL 105 00:07:43,760 --> 00:07:48,995 na mensagem de solicitação indicando o que você deseja que o lado do servidor lhe envie. 106 00:07:48,995 --> 00:07:52,660 E isso geralmente é uma mensagem GET se você quiser que 107 00:07:52,660 --> 00:07:57,440 os dados sejam baixados do lado do servidor. 108 00:07:57,440 --> 00:08:02,110 Você também especificará com qual servidor específico você está se comunicando. 109 00:08:02,110 --> 00:08:04,864 Quando o servidor recebe sua solicitação, 110 00:08:04,864 --> 00:08:09,325 o servidor recuperará os dados de seu armazenamento de dados, 111 00:08:09,325 --> 00:08:11,980 geralmente um banco de dados no lado do servidor 112 00:08:11,980 --> 00:08:14,250 e, em seguida, empacotará esses dados em 113 00:08:14,250 --> 00:08:20,420 um formato apropriado e enviará os dados de volta para você no lado do cliente. 114 00:08:20,420 --> 00:08:23,285 Se você estiver obtendo HTML padrão, CSS 115 00:08:23,285 --> 00:08:25,240 e código JavaScript do lado do servidor, 116 00:08:25,240 --> 00:08:27,310 então seu navegador é capaz de renderizar isso. 117 00:08:27,310 --> 00:08:30,144 Mas com aplicativos como Angular, 118 00:08:30,144 --> 00:08:32,830 você está se conectando principalmente ao servidor e, em seguida, 119 00:08:32,830 --> 00:08:39,700 recuperando dados na forma de JSON ou XML a maior parte do tempo. 120 00:08:39,700 --> 00:08:44,200 Exceto para o download inicial de todos os recursos necessários 121 00:08:44,200 --> 00:08:49,245 para que seu aplicativo Angular seja executado dentro de seu navegador. 122 00:08:49,245 --> 00:08:51,090 Então, como vimos anteriormente, 123 00:08:51,090 --> 00:08:59,139 o aplicativo HTTP requer mensagens a serem enviadas entre o cliente e o servidor. 124 00:08:59,139 --> 00:09:03,615 Normalmente, uma mensagem de solicitação é enviada do cliente para o servidor e 125 00:09:03,615 --> 00:09:09,500 a mensagem de solicitação consiste em uma linha de solicitação mais um monte de cabeçalhos, 126 00:09:09,500 --> 00:09:14,170 onde você fornece informações adicionais para qualificar a solicitação. 127 00:09:14,170 --> 00:09:17,410 Veremos o uso de vários cabeçalhos e configurações 128 00:09:17,410 --> 00:09:23,425 nos cabeçalhos à medida que passamos por alguns dos exercícios neste módulo particular. 129 00:09:23,425 --> 00:09:27,045 A linha de solicitação e os cabeçalhos são separados do corpo 130 00:09:27,045 --> 00:09:31,280 da mensagem de solicitação por uma linha em branco. 131 00:09:31,280 --> 00:09:34,300 O corpo da mensagem pode conter dados adicionais, 132 00:09:34,300 --> 00:09:38,460 especialmente se o cliente estiver enviando dados para o lado do servidor. 133 00:09:38,460 --> 00:09:40,735 Por exemplo, quando você envia um formulário, 134 00:09:40,735 --> 00:09:45,190 as informações contidas no formulário são codificadas em 135 00:09:45,190 --> 00:09:51,115 um formato JSON e, em seguida, enviadas para o lado do servidor a partir do lado do cliente. 136 00:09:51,115 --> 00:09:55,640 Então isso será feito usando um POST ou uma mensagem PUT. 137 00:09:55,640 --> 00:10:00,374 Olhando para o pouco mais detalhes da mensagem de solicitação HTTP, 138 00:10:00,374 --> 00:10:02,500 a mensagem de solicitação típica 139 00:10:02,500 --> 00:10:06,140 na linha de solicitação conterá o método que é GET, PUT, POST, 140 00:10:06,140 --> 00:10:10,225 DELETE ou alguns dos outros verbos que você viu anteriormente 141 00:10:10,225 --> 00:10:13,735 e, em seguida, seguido pela URL e a versão 142 00:10:13,735 --> 00:10:19,260 do Protocolo HTTP que você está usando para se comunicar do cliente para o lado do servidor. 143 00:10:19,260 --> 00:10:23,250 O campo de cabeçalho geralmente contém um nome de campo de cabeçalho, 144 00:10:23,250 --> 00:10:27,310 dois pontos e o valor para esse campo de cabeçalho. 145 00:10:27,310 --> 00:10:30,020 E o conteúdo do corpo, como mencionei, 146 00:10:30,020 --> 00:10:36,090 poderia ser codificado em formato JSON ou XML. 147 00:10:36,090 --> 00:10:39,355 Aqui está um exemplo de 148 00:10:39,355 --> 00:10:46,040 uma mensagem de solicitação HTTP típica que pode ser enviada para o servidor a partir do cliente. 149 00:10:46,040 --> 00:10:48,000 Então, nesta mensagem de solicitação específica, 150 00:10:48,000 --> 00:10:52,540 estamos pedindo ao servidor para reter a página index.html 151 00:10:52,540 --> 00:10:55,150 do lado do servidor para o lado do cliente para que ele 152 00:10:55,150 --> 00:10:58,100 possa ser processado no navegador no lado do cliente. 153 00:10:58,100 --> 00:11:03,790 Uma solicitação como essa normalmente teria um corpo vazio na mensagem de solicitação. 154 00:11:03,790 --> 00:11:06,460 A maioria das informações será codificada 155 00:11:06,460 --> 00:11:11,755 na linha de solicitação mais os cabeçalhos da mensagem de solicitação. 156 00:11:11,755 --> 00:11:15,935 Quando o cliente envia a solicitação para o servidor. 157 00:11:15,935 --> 00:11:22,120 O servidor processará a solicitação e, em seguida, enviará uma resposta para o lado do cliente. 158 00:11:22,120 --> 00:11:26,150 A mensagem de resposta é organizada novamente em três partes, 159 00:11:26,150 --> 00:11:30,850 uma linha de status onde algumas informações sobre como 160 00:11:30,850 --> 00:11:35,648 a solicitação foi processada e o que está sendo enviado de volta para o cliente é armazenado, 161 00:11:35,648 --> 00:11:40,270 os cabeçalhos conterão detalhes adicionais do que está 162 00:11:40,270 --> 00:11:45,145 contido na mensagem de resposta e, em seguida, seguido por uma linha em branco 163 00:11:45,145 --> 00:11:49,355 e, em seguida, o corpo real da mensagem. 164 00:11:49,355 --> 00:11:55,405 Um exemplo do que seria normalmente contido em uma mensagem de resposta HTTP, 165 00:11:55,405 --> 00:11:59,875 neste caso, essa mensagem de resposta está voltando com um 200, 166 00:11:59,875 --> 00:12:03,260 que é um código de status da mensagem. 167 00:12:03,260 --> 00:12:07,420 Se você vir um 200 na linha de solicitação como um código de status, 168 00:12:07,420 --> 00:12:11,770 isso significa que sua solicitação foi bem-sucedida e o servidor é capaz de 169 00:12:11,770 --> 00:12:16,920 retornar os dados que você solicitou do lado do servidor. 170 00:12:16,920 --> 00:12:22,180 E, em seguida, o cabeçalho irá conter direções adicionais para 171 00:12:22,180 --> 00:12:25,165 o lado do cliente, incluindo informações sobre 172 00:12:25,165 --> 00:12:29,425 como o corpo real da mensagem é codificado. 173 00:12:29,425 --> 00:12:31,705 Em seguida, o corpo pode conter, 174 00:12:31,705 --> 00:12:34,565 se você solicitou a página index.html, 175 00:12:34,565 --> 00:12:39,670 o corpo da mensagem conterá o código HTML para 176 00:12:39,670 --> 00:12:45,515 a página index.html como você vê neste exemplo aqui. 177 00:12:45,515 --> 00:12:53,955 Uma das informações na linha de status a que me refiro como o código de status. 178 00:12:53,955 --> 00:12:58,080 Se o servidor for capaz de processar sua solicitação corretamente, 179 00:12:58,080 --> 00:13:01,852 ele enviará de volta uma resposta com um código de status de 200, o 180 00:13:01,852 --> 00:13:04,330 que significa que tudo está bem no lado do servidor e 181 00:13:04,330 --> 00:13:07,685 o lado do servidor está retornando os dados corretamente. 182 00:13:07,685 --> 00:13:12,055 Se o servidor não conseguir processar a solicitação por qualquer motivo 183 00:13:12,055 --> 00:13:14,800 , essas informações serão codificadas 184 00:13:14,800 --> 00:13:20,020 no código de status na linha de status da mensagem de resposta. 185 00:13:20,020 --> 00:13:24,160 Os vários códigos de status normalmente que você encontrará quando você 186 00:13:24,160 --> 00:13:28,355 recebe uma resposta do lado do servidor incluem um 201, o 187 00:13:28,355 --> 00:13:30,985 que significa que quando você tenta criar 188 00:13:30,985 --> 00:13:34,540 um objeto no lado do servidor ele foi criado com sucesso, 189 00:13:34,540 --> 00:13:39,100 ou um 301, o que significa que o que você está solicitando foi movido permanentemente 190 00:13:39,100 --> 00:13:42,365 para um novo local e a URL 191 00:13:42,365 --> 00:13:46,965 do novo local desse recurso será retornada para o lado do cliente. 192 00:13:46,965 --> 00:13:52,775 400s e 500s normalmente indicam que há algum problema no lado do servidor. 193 00:13:52,775 --> 00:13:57,310 404 é algo que você encontra frequentemente quando 194 00:13:57,310 --> 00:14:02,260 você solicita algo que não existe no lado do servidor. 195 00:14:02,260 --> 00:14:05,620 Da mesma forma, 500 significa que o servidor está apenas desistindo, 196 00:14:05,620 --> 00:14:10,390 não é capaz de processar sua solicitação e, em seguida, envia de volta um erro interno do servidor. 197 00:14:10,390 --> 00:14:14,445 Estes são dois códigos de erro comuns que você encontrará. 198 00:14:14,445 --> 00:14:20,355 Os restantes têm significado específico conforme listado nesta tabela aqui. 199 00:14:20,355 --> 00:14:24,483 Há mais do que os códigos de status que eu lhe dei nesta tabela, 200 00:14:24,483 --> 00:14:27,963 mas estes são alguns dos códigos de status mais comuns que você 201 00:14:27,963 --> 00:14:32,835 encontrará em uma mensagem de resposta vinda do lado do servidor. 202 00:14:32,835 --> 00:14:37,420 Outro ponto que mencionei é o fato de que o servidor pode codificar 203 00:14:37,420 --> 00:14:46,880 os dados em um formato específico como XML ou Extended Markup Language ou JSON, 204 00:14:46,880 --> 00:14:50,845 o formato JavaScript Object Notation. 205 00:14:50,845 --> 00:14:53,950 Agora, tipicamente, neste curso particular, 206 00:14:53,950 --> 00:14:57,700 estaremos lidando com dados que são codificados principalmente em JSON. 207 00:14:57,700 --> 00:15:02,875 A maioria dos aplicativos do lado do cliente, 208 00:15:02,875 --> 00:15:06,680 incluindo aplicativos móveis atualmente, normalmente se comunica com 209 00:15:06,680 --> 00:15:16,515 o servidor e o formato de troca de dados é JSON por padrão na maioria dos casos. 210 00:15:16,515 --> 00:15:22,125 Essa é a razão pela qual vou gastar alguns minutos explicando sobre JSON. 211 00:15:22,125 --> 00:15:27,785 O JavaScript Object Notation ou JSON é um formato leve de intercâmbio de dados. 212 00:15:27,785 --> 00:15:33,100 A razão pela qual o formato de dados JSON é especificamente de 213 00:15:33,100 --> 00:15:38,685 interesse para nós neste curso é porque a Notação de Objeto JavaScript, 214 00:15:38,685 --> 00:15:40,710 como o nome indica, 215 00:15:40,710 --> 00:15:46,840 mapeia facilmente em um objeto JavaScript que você usa com qualquer código JavaScript. 216 00:15:46,840 --> 00:15:50,430 Portanto, converter um objeto JavaScript 217 00:15:50,430 --> 00:15:53,725 em notação JSON e vice-versa é muito simples. 218 00:15:53,725 --> 00:15:57,420 A notação JSON é o que chamamos de 219 00:15:57,420 --> 00:16:01,815 auto-descrição e muito fácil de entender notação. 220 00:16:01,815 --> 00:16:05,103 No formato JavaScript Object Notation, 221 00:16:05,103 --> 00:16:11,040 os dados são estruturados de uma maneira muito limpa e especificada. 222 00:16:11,040 --> 00:16:14,693 Isso é estruturado como uma coleção de nomes, pares de valores, 223 00:16:14,693 --> 00:16:19,610 e isso é estruturado como uma lista ordenada de valores. 224 00:16:19,610 --> 00:16:23,375 Você pode ver um exemplo disso no lado direito aqui. 225 00:16:23,375 --> 00:16:30,750 Nós realmente usamos esses dados JSON dentro de nossa aplicação angular já anteriormente. 226 00:16:30,750 --> 00:16:35,570 Então, agora você vê por que os dados são estruturados dessa maneira. 227 00:16:35,570 --> 00:16:41,220 E você também percebe que é muito fácil ser capaz de lidar com 228 00:16:41,220 --> 00:16:47,850 esses dados dentro de seu JavaScript ou seu código TypeScript em seu aplicativo Angular. 229 00:16:47,850 --> 00:16:55,000 Com isso, concluo uma visão geral rápida dos fundamentos de rede.