1 00:00:01,670 --> 00:00:04,320 ‫Instrutor: Agora que sabemos o que é 2 00:00:04,320 --> 00:00:07,550 ‫Express, estamos quase prontos para começar a construir nossa API. 3 00:00:07,550 --> 00:00:08,890 ‫Mas antes de 4 00:00:08,890 --> 00:00:12,300 ‫fazermos isso, preciso falar rapidamente sobre APIs em um nível 5 00:00:12,300 --> 00:00:13,910 ‫superior e, mais importante, 6 00:00:13,910 --> 00:00:16,370 ‫apresentar a você a Arquitetura REST, 7 00:00:16,370 --> 00:00:19,640 ‫que é a arquitetura de API mais usada atualmente. 8 00:00:19,640 --> 00:00:23,270 ‫Dessa forma, saberemos realmente o que estamos construindo. 9 00:00:23,270 --> 00:00:25,710 ‫Portanto, é extremamente importante entender as coisas neste 10 00:00:25,710 --> 00:00:27,860 ‫vídeo antes de prosseguir, para que 11 00:00:27,860 --> 00:00:30,580 ‫possamos realmente saber o que estamos construindo ao 12 00:00:30,580 --> 00:00:32,603 ‫longo do resto do curso. 13 00:00:33,630 --> 00:00:34,890 ‫Em primeiro 14 00:00:34,890 --> 00:00:38,390 ‫lugar, API significa Interface de Programação de Aplicativo e, 15 00:00:38,390 --> 00:00:40,130 ‫em um nível muito 16 00:00:40,130 --> 00:00:43,150 ‫alto, é basicamente um software que pode 17 00:00:43,150 --> 00:00:45,270 ‫ser usado por outro software 18 00:00:45,270 --> 00:00:48,213 ‫para permitir que os aplicativos se comuniquem. 19 00:00:49,080 --> 00:00:51,420 ‫Na verdade, já falamos sobre 20 00:00:51,420 --> 00:00:53,780 ‫APIs antes, mais especificamente, APIs da web, 21 00:00:53,780 --> 00:00:56,300 ‫onde simplesmente construímos um aplicativo que envia 22 00:00:56,300 --> 00:00:59,640 ‫dados a um cliente sempre que uma solicitação chega. 23 00:00:59,640 --> 00:01:02,530 ‫Imagine que temos nosso aplicativo rodando em um servidor 24 00:01:02,530 --> 00:01:04,060 ‫e temos um cliente. 25 00:01:04,060 --> 00:01:08,020 ‫Então, na verdade, temos dois softwares 26 00:01:08,020 --> 00:01:10,250 ‫conversando, certo? 27 00:01:10,250 --> 00:01:13,550 ‫E esse é o tipo de API que construiremos neste curso. 28 00:01:13,550 --> 00:01:17,470 ‫E eu acho que é o tipo de API mais usado por aí. 29 00:01:17,470 --> 00:01:21,970 ‫Mas, na verdade, as APIs não são usadas apenas para enviar dados e 30 00:01:21,970 --> 00:01:25,493 ‫nem sempre estão relacionadas ao desenvolvimento web ou JavaScript. 31 00:01:26,400 --> 00:01:29,500 ‫O aplicativo na API pode significar 32 00:01:29,500 --> 00:01:32,710 ‫muitas coisas diferentes, desde que o 33 00:01:32,710 --> 00:01:35,050 ‫software seja relativamente independente. 34 00:01:35,050 --> 00:01:35,900 ‫Considere, por 35 00:01:35,900 --> 00:01:38,870 ‫exemplo, o Node File System ou os Módulos HTTP. 36 00:01:38,870 --> 00:01:42,010 ‫Podemos dizer que são pequenos softwares 37 00:01:42,010 --> 00:01:43,110 ‫e podemos 38 00:01:43,110 --> 00:01:46,970 ‫usá-los, podemos interagir com eles usando sua API. 39 00:01:46,970 --> 00:01:47,803 ‫Por 40 00:01:47,803 --> 00:01:51,150 ‫exemplo, quando usamos a função readfile do Módulo FS, 41 00:01:51,150 --> 00:01:54,020 ‫na verdade estamos usando a API FS. 42 00:01:54,020 --> 00:01:57,380 ‫E é por isso que você às vezes ouvirá o termo APIs de nó. 43 00:01:57,380 --> 00:02:01,090 ‫E isso geralmente se refere simplesmente aos módulos do nó central 44 00:02:01,090 --> 00:02:02,920 ‫com os quais podemos interagir. 45 00:02:02,920 --> 00:02:05,670 ‫Ou quando fazemos a manipulação do DOM no 46 00:02:05,670 --> 00:02:08,650 ‫navegador, não estamos realmente usando a linguagem JavaScript em si, 47 00:02:08,650 --> 00:02:12,440 ‫mas sim a API DOM que o navegador nos expõe, de modo que 48 00:02:12,440 --> 00:02:14,280 ‫nos dá acesso a ela. 49 00:02:14,280 --> 00:02:15,930 ‫Ou até mesmo outro exemplo, 50 00:02:15,930 --> 00:02:19,080 ‫digamos que criamos uma classe em qualquer linguagem de programação 51 00:02:19,080 --> 00:02:21,940 ‫como Java e, em seguida, adicionamos alguns métodos públicos 52 00:02:21,940 --> 00:02:23,420 ‫ou propriedades a ela. 53 00:02:23,420 --> 00:02:26,860 ‫Esses métodos serão então a API de cada 54 00:02:26,860 --> 00:02:29,450 ‫objeto criado a partir dessa classe, 55 00:02:29,450 --> 00:02:31,890 ‫pois estamos dando a outros softwares 56 00:02:31,890 --> 00:02:35,420 ‫a possibilidade de interagir com nosso software inicial, os 57 00:02:35,420 --> 00:02:37,278 ‫objetos, neste caso. 58 00:02:37,278 --> 00:02:40,810 ‫Veja, API tem um significado mais amplo do que 59 00:02:40,810 --> 00:02:42,810 ‫apenas construir APIs da web. 60 00:02:42,810 --> 00:02:47,420 ‫Tudo bem? De qualquer forma, uma API da web 61 00:02:47,420 --> 00:02:50,340 ‫é o mais importante para nós no contexto da observação. 62 00:02:50,340 --> 00:02:53,050 ‫Vamos agora dar uma olhada na Arquitetura REST 63 00:02:53,050 --> 00:02:54,203 ‫para construir APIs. 64 00:02:55,820 --> 00:02:59,910 ‫REST, que significa Representational States Transfer, é basicamente uma forma 65 00:02:59,910 --> 00:03:03,930 ‫de construir APIs da web de uma forma lógica, 66 00:03:03,930 --> 00:03:06,060 ‫tornando-as fáceis de consumir 67 00:03:06,060 --> 00:03:09,420 ‫porque lembre-se, nós construímos uma API para nós 68 00:03:09,420 --> 00:03:12,023 ‫mesmos ou para outros consumirem, ok? 69 00:03:12,023 --> 00:03:15,640 ‫Queremos tornar o processo de uso da API o mais 70 00:03:15,640 --> 00:03:17,633 ‫suave possível para o usuário. 71 00:03:18,490 --> 00:03:20,830 ‫Agora, para construir APIs 72 00:03:20,830 --> 00:03:24,180 ‫RESTful, o que significa APIs seguindo a Arquitetura 73 00:03:24,180 --> 00:03:26,660 ‫REST, precisamos apenas seguir alguns princípios. 74 00:03:26,660 --> 00:03:31,240 ‫Primeiro, precisamos separar nossa API em recursos lógicos. 75 00:03:31,240 --> 00:03:33,860 ‫Esses recursos devem então ser expostos, o 76 00:03:33,860 --> 00:03:35,900 ‫que significa que devem ser 77 00:03:35,900 --> 00:03:39,420 ‫disponibilizados por meio de URLs estruturados e baseados em recursos. 78 00:03:39,420 --> 00:03:41,460 ‫Para realizar diferentes ações 79 00:03:41,460 --> 00:03:44,677 ‫nos dados, como ler, criar ou excluir dados, 80 00:03:44,677 --> 00:03:49,677 ‫a API deve usar os métodos HTP corretos e não o URL. 81 00:03:50,270 --> 00:03:53,210 ‫Agora, os dados que realmente enviamos de volta ao 82 00:03:53,210 --> 00:03:55,420 ‫cliente ou que recebemos do cliente 83 00:03:55,420 --> 00:03:58,030 ‫geralmente devem usar o formato de dados JSON, 84 00:03:58,030 --> 00:04:01,010 ‫onde algum padrão de formatação se aplica a ele. 85 00:04:01,010 --> 00:04:04,500 ‫Finalmente, outro princípio importante das APIs REST é 86 00:04:04,500 --> 00:04:07,560 ‫que elas devem ser sem estado. 87 00:04:07,560 --> 00:04:09,950 ‫Portanto, esta é uma visão geral muito ampla. 88 00:04:09,950 --> 00:04:12,030 ‫Agora vamos começar a falar sobre 89 00:04:12,030 --> 00:04:15,310 ‫esses princípios um por um, começando com recursos e usando 90 00:04:15,310 --> 00:04:17,810 ‫a API Nators que iremos construir neste 91 00:04:17,810 --> 00:04:19,803 ‫curso como um exemplo aqui. 92 00:04:20,960 --> 00:04:24,910 ‫A abstração chave das informações no REST é um recurso 93 00:04:24,910 --> 00:04:27,450 ‫e, portanto, todos os dados 94 00:04:27,450 --> 00:04:32,040 ‫que queremos compartilhar na API devem ser divididos em recursos lógicos. 95 00:04:32,040 --> 00:04:34,350 ‫Agora, o que realmente é um recurso? 96 00:04:34,350 --> 00:04:36,380 ‫Bem, no contexto do 97 00:04:36,380 --> 00:04:39,520 ‫REST, é um objeto ou uma representação de algo 98 00:04:39,520 --> 00:04:42,020 ‫que possui alguns dados associados a ele. 99 00:04:42,020 --> 00:04:42,853 ‫Por 100 00:04:42,853 --> 00:04:45,570 ‫exemplo, passeios, ou usuários, ou comentários no 101 00:04:45,570 --> 00:04:48,020 ‫caso do exemplo que estamos seguindo. 102 00:04:48,020 --> 00:04:50,730 ‫Então, basicamente, qualquer informação que possa ser nomeada 103 00:04:50,730 --> 00:04:53,040 ‫pode ser um recurso, certo? 104 00:04:53,040 --> 00:04:56,050 ‫Só precisa ser um nome, não um verbo. 105 00:04:56,050 --> 00:04:57,690 ‫Agora, precisamos expor, 106 00:04:57,690 --> 00:04:59,480 ‫o que significa disponibilizar, os 107 00:04:59,480 --> 00:05:02,520 ‫dados usando algumas URLs estruturadas para as quais 108 00:05:02,520 --> 00:05:04,890 ‫o cliente pode enviar uma solicitação. 109 00:05:04,890 --> 00:05:07,611 ‫Por exemplo, algo assim. 110 00:05:07,611 --> 00:05:10,740 ‫Todo esse endereço é chamado de URL 111 00:05:10,740 --> 00:05:14,323 ‫e este / addNewTour é chamado de endpoint de API. 112 00:05:15,269 --> 00:05:17,840 ‫Nossa API terá muitos endpoints diferentes, assim 113 00:05:17,840 --> 00:05:20,560 ‫como estes endpoints fictícios que tenho aqui, cada 114 00:05:20,560 --> 00:05:23,730 ‫um dos quais enviará dados diferentes de volta ao 115 00:05:23,730 --> 00:05:26,150 ‫cliente ou também executará ações diferentes. 116 00:05:26,150 --> 00:05:28,440 ‫Agora, há realmente algo muito 117 00:05:28,440 --> 00:05:31,750 ‫errado com esses endpoints aqui porque eles realmente não 118 00:05:31,750 --> 00:05:34,827 ‫seguem a terceira regra que diz que 119 00:05:34,827 --> 00:05:39,110 ‫devemos usar apenas os métodos HTTP para realizar ações nos dados. 120 00:05:39,110 --> 00:05:42,360 ‫Portanto, os endpoints devem conter apenas nossos recursos e 121 00:05:42,360 --> 00:05:45,070 ‫não as ações que podem ser executadas 122 00:05:45,070 --> 00:05:48,313 ‫neles, pois sua manutenção se tornará rapidamente um pesadelo. 123 00:05:49,644 --> 00:05:54,210 ‫Como devemos usar esses métodos HTTP na prática? 124 00:05:54,210 --> 00:05:56,120 ‫Bem, vamos ver como esses 125 00:05:56,120 --> 00:05:59,620 ‫pontos de extremidade devem realmente parecer começando com / getTour. 126 00:05:59,620 --> 00:06:03,290 ‫Portanto, este ponto de extremidade / getTour é para obter dados sobre um passeio. 127 00:06:03,290 --> 00:06:06,240 ‫Portanto, devemos simplesmente nomear o endpoint / tours e enviar 128 00:06:06,240 --> 00:06:08,740 ‫os dados sempre que uma solicitação get for 129 00:06:08,740 --> 00:06:10,430 ‫feita para esse endpoint. 130 00:06:10,430 --> 00:06:11,650 ‫Em outras 131 00:06:11,650 --> 00:06:14,730 ‫palavras, quando um cliente usa um método GET 132 00:06:14,730 --> 00:06:16,700 ‫HTTP para acessar o terminal. 133 00:06:16,700 --> 00:06:17,870 ‫E assim, 134 00:06:17,870 --> 00:06:20,220 ‫só temos recursos no endpoint 135 00:06:20,220 --> 00:06:23,670 ‫ou na URL e nenhum verbo porque o 136 00:06:23,670 --> 00:06:26,870 ‫verbo agora está no método HTTP, certo? 137 00:06:26,870 --> 00:06:27,703 ‫E, a 138 00:06:27,703 --> 00:06:30,490 ‫propósito, é uma prática comum sempre usar o nome 139 00:06:30,490 --> 00:06:34,820 ‫do recurso no plural, por isso tenho / tours aqui e não / tour. 140 00:06:34,820 --> 00:06:37,790 ‫Agora, a convenção é que, ao chamar esse 141 00:06:37,790 --> 00:06:41,820 ‫endpoint, recebemos todos os passeios que estão em um banco de dados, certo? 142 00:06:41,820 --> 00:06:44,820 ‫Mas se quisermos apenas a turnê com um I. D. digamos sete, adicionamos 143 00:06:44,820 --> 00:06:48,960 ‫esse sete após outra barra ou em uma consulta de pesquisa. 144 00:06:48,960 --> 00:06:50,580 ‫Ou também pode ser o nome de um passeio em vez de I. D. ou algum outro identificador exclusivo. 145 00:06:50,580 --> 00:06:53,490 ‫O detalhe realmente não importa neste ponto, certo? 146 00:06:53,490 --> 00:06:55,410 ‫Posteriormente, mostrarei como é fácil 147 00:06:55,410 --> 00:06:58,300 ‫implementar esse tipo de lógica com o Express porque 148 00:06:58,300 --> 00:07:01,180 ‫é aqui que o Express realmente se destaca. 149 00:07:01,180 --> 00:07:03,410 ‫O primeiro método HTTP ou 150 00:07:03,410 --> 00:07:06,733 ‫verbo ao qual podemos responder é GET e é 151 00:07:07,606 --> 00:07:10,460 ‫usado para realizar a operação Read nos dados. 152 00:07:10,460 --> 00:07:12,530 ‫Próxima parada, se o cliente 153 00:07:12,530 --> 00:07:16,290 ‫deseja criar um novo recurso em nosso banco de 154 00:07:16,290 --> 00:07:18,290 ‫dados, neste exemplo, um 155 00:07:18,290 --> 00:07:21,450 ‫novo tour, deve-se utilizar o método POST. 156 00:07:21,450 --> 00:07:23,200 ‫Portanto, aprendemos anteriormente que uma solicitação 157 00:07:23,200 --> 00:07:25,510 ‫POST pode ser usada para enviar dados 158 00:07:25,510 --> 00:07:28,490 ‫ao servidor e, portanto, faz sentido usar POST para 159 00:07:28,490 --> 00:07:30,230 ‫criar novos recursos, certo? 160 00:07:30,230 --> 00:07:32,270 ‫Agora, neste caso, geralmente não. D. será enviado porque 161 00:07:32,270 --> 00:07:35,530 ‫o servidor deve descobrir automaticamente o 162 00:07:35,530 --> 00:07:38,530 ‫I. D. para o novo recurso. 163 00:07:38,530 --> 00:07:40,860 ‫De qualquer forma, o que é realmente importante observar aqui é como o nome do terminal é exatamente 164 00:07:40,860 --> 00:07:42,948 ‫o mesmo nome de antes. 165 00:07:42,948 --> 00:07:46,090 ‫A única diferença é realmente 166 00:07:46,090 --> 00:07:50,289 ‫o método HTP usado para a solicitação. 167 00:07:50,289 --> 00:07:53,870 ‫Se o endpoint / tours for acessado com GET, 168 00:07:53,870 --> 00:07:55,960 ‫enviamos os dados ao cliente. 169 00:07:55,960 --> 00:07:59,410 ‫Mas se o mesmo endpoint for acessado com POST, esperamos 170 00:07:59,410 --> 00:08:01,460 ‫que os dados cheguem 171 00:08:01,460 --> 00:08:04,060 ‫com uma solicitação, para que possamos criar 172 00:08:04,060 --> 00:08:06,550 ‫um novo recurso no lado do servidor. 173 00:08:06,550 --> 00:08:08,760 ‫Portanto, essa é realmente a beleza de usar apenas métodos HTTP em vez 174 00:08:08,760 --> 00:08:10,330 ‫de mexer com verbos em nomes de terminais. 175 00:08:10,330 --> 00:08:14,460 ‫Novamente, isso realmente se tornaria incontrolável muito rápido. 176 00:08:14,460 --> 00:08:17,480 ‫Tudo bem, em seguida, também 177 00:08:17,480 --> 00:08:21,210 ‫deve haver a capacidade de atualizar recursos. 178 00:08:21,210 --> 00:08:23,620 ‫E para isso, uma solicitação PUT 179 00:08:23,620 --> 00:08:26,390 ‫ou PATCH deve ser feita ao 180 00:08:26,390 --> 00:08:27,310 ‫terminal. 181 00:08:27,310 --> 00:08:29,550 ‫A diferença entre eles é que com 182 00:08:29,550 --> 00:08:31,550 ‫PUT, o cliente deve enviar todo 183 00:08:31,550 --> 00:08:33,750 ‫o objeto atualizado, enquanto que com 184 00:08:33,750 --> 00:08:37,280 ‫PATCH, ele deve enviar apenas a parte do objeto que 185 00:08:37,280 --> 00:08:38,370 ‫foi alterada. 186 00:08:38,370 --> 00:08:40,967 ‫Mas ambos têm a capacidade de 187 00:08:40,967 --> 00:08:43,060 ‫enviar dados ao servidor. 188 00:08:43,060 --> 00:08:45,140 ‫Um pouco como o POST, na verdade, mas com uma intenção diferente. 189 00:08:45,140 --> 00:08:46,750 ‫Então POST é 190 00:08:46,750 --> 00:08:50,750 ‫para criar um novo recurso, enquanto PUT ou PATCH são 191 00:08:50,750 --> 00:08:53,070 ‫usados para atualizar um recurso existente 192 00:08:53,070 --> 00:08:55,370 ‫e então faz toda a diferença. 193 00:08:55,370 --> 00:08:57,500 ‫E por fim, para o recurso 194 00:08:57,500 --> 00:08:59,660 ‫de lixo, existe o método DELETE HTTP. 195 00:08:59,660 --> 00:09:02,110 ‫Novamente, o I. D. ou algum outro identificador exclusivo do 196 00:09:02,110 --> 00:09:05,110 ‫recurso a ser excluído deve fazer parte da 197 00:09:05,110 --> 00:09:08,010 ‫URL. 198 00:09:08,010 --> 00:09:10,120 ‫Agora, normalmente, para poder realmente 199 00:09:10,120 --> 00:09:11,820 ‫realizar esse tipo 200 00:09:11,820 --> 00:09:14,560 ‫de solicitação, o cliente deve estar autenticado. 201 00:09:14,560 --> 00:09:16,610 ‫Então, basicamente, faça login em seu aplicativo, certo? 202 00:09:16,610 --> 00:09:18,620 ‫Mas esse é, obviamente, um assunto para muito mais tarde. 203 00:09:18,620 --> 00:09:21,670 ‫Portanto, esses são os cinco métodos HTTP 204 00:09:21,670 --> 00:09:24,349 ‫aos quais podemos e devemos responder 205 00:09:24,349 --> 00:09:27,080 ‫ao construir nossas APIs RESTful para que 206 00:09:27,080 --> 00:09:29,320 ‫o cliente possa realizar 207 00:09:29,320 --> 00:09:31,570 ‫as quatro operações CRUD básicas. 208 00:09:31,570 --> 00:09:33,270 ‫Portanto, CRUD significa Criar, Ler, Atualizar e Excluir. 209 00:09:33,270 --> 00:09:36,290 ‫E você verá esse termo o 210 00:09:36,290 --> 00:09:40,730 ‫tempo todo relacionado a APIs e coisas de banco de dados. 211 00:09:40,730 --> 00:09:42,590 ‫E você vê que esses métodos 212 00:09:42,590 --> 00:09:45,200 ‫HTTP mapeiam muito bem para as operações CRUD básicas. 213 00:09:45,200 --> 00:09:47,490 ‫Agora, pode haver ações 214 00:09:47,490 --> 00:09:51,330 ‫que não são CRUD e, nesse caso, só 215 00:09:51,330 --> 00:09:54,410 ‫precisamos ser criativos com nossas entradas. 216 00:09:54,410 --> 00:09:55,460 ‫Por exemplo, um 217 00:09:55,460 --> 00:09:58,120 ‫login ou uma operação de pesquisa, eles não estão 218 00:09:58,120 --> 00:09:58,953 ‫realmente relacionados 219 00:09:58,953 --> 00:10:01,010 ‫a um recurso específico e também não 220 00:10:01,010 --> 00:10:04,361 ‫são operações CRUD, mas ainda podemos criar pontos de extremidade para eles. 221 00:10:04,361 --> 00:10:06,630 ‫Por exemplo, como / login ou / search. 222 00:10:06,630 --> 00:10:09,240 ‫Mas falaremos mais sobre esses casos mais tarde na prática. 223 00:10:09,240 --> 00:10:12,530 ‫E só para terminar esta parte agora, lembre-se 224 00:10:12,530 --> 00:10:16,350 ‫de que tínhamos dois outros nomes de endpoint malucos 225 00:10:16,350 --> 00:10:18,290 ‫no último slide que 226 00:10:18,290 --> 00:10:21,330 ‫envolviam dois recursos ao mesmo tempo, certo? 227 00:10:21,330 --> 00:10:23,870 ‫E isso também não é nenhum problema com REST. 228 00:10:23,870 --> 00:10:26,780 ‫Portanto, / getToursByUser pode 229 00:10:26,780 --> 00:10:29,888 ‫ser simplesmente traduzido para / users 230 00:10:29,888 --> 00:10:33,810 ‫/ tours, neste caso, o usuário número três. 231 00:10:33,810 --> 00:10:36,210 ‫Portanto, este ponto de extremidade específico aqui pode 232 00:10:36,210 --> 00:10:38,440 ‫enviar dados sobre todos os passeios que 233 00:10:38,440 --> 00:10:40,200 ‫o usuário número três reservou. 234 00:10:40,200 --> 00:10:42,340 ‫Faz sentido? 235 00:10:42,340 --> 00:10:44,580 ‫Ou, no caso de exclusão, pode haver uma 236 00:10:44,580 --> 00:10:45,519 ‫solicitação de 237 00:10:45,519 --> 00:10:47,470 ‫exclusão para o mesmo endpoint ou 238 00:10:47,470 --> 00:10:50,170 ‫muito semelhante, solicitando que o tour número nove seja 239 00:10:50,170 --> 00:10:51,910 ‫excluído do usuário número três, certo? 240 00:10:51,910 --> 00:10:54,440 ‫Portanto, existem muitas possibilidades 241 00:10:54,440 --> 00:10:57,330 ‫de combinar recursos como este. 242 00:10:57,330 --> 00:11:00,160 ‫Mas é claro, não precisamos implementar todas 243 00:11:00,160 --> 00:11:02,470 ‫essas combinações em nossa API. 244 00:11:02,470 --> 00:11:04,260 ‫Implementamos apenas o que faz 245 00:11:04,260 --> 00:11:06,600 ‫sentido no caso de nossa aplicação e do 246 00:11:06,600 --> 00:11:08,400 ‫cliente que deseja consumir nossa API. 247 00:11:08,400 --> 00:11:10,090 ‫Portanto, é assim que 248 00:11:10,090 --> 00:11:13,203 ‫usamos métodos HTTP para construir URLs amigáveis e 249 00:11:13,203 --> 00:11:17,480 ‫bem estruturados que são fáceis e lógicos de consumir para o cliente. 250 00:11:17,480 --> 00:11:20,823 ‫Agora, sobre os dados que o cliente realmente 251 00:11:20,823 --> 00:11:24,145 ‫recebe, ou que o servidor recebe 252 00:11:24,145 --> 00:11:27,800 ‫do cliente, normalmente usamos o formato de dados JSON. 253 00:11:27,800 --> 00:11:30,610 ‫Então, vamos aprender brevemente o que JSON realmente é 254 00:11:30,610 --> 00:11:33,203 ‫e como formatar nossas respostas de API. 255 00:11:34,440 --> 00:11:37,400 ‫JSON é um formato de intercâmbio de 256 00:11:37,400 --> 00:11:39,530 ‫dados muito leve, muito 257 00:11:39,530 --> 00:11:43,780 ‫usado por APIs da web codificadas em qualquer linguagem de programação. 258 00:11:43,780 --> 00:11:46,220 ‫Portanto, não está relacionado a um JavaScript. 259 00:11:46,220 --> 00:11:48,160 ‫E é tão amplamente usado hoje 260 00:11:48,160 --> 00:11:50,740 ‫porque é muito fácil para humanos e computadores 261 00:11:50,740 --> 00:11:52,620 ‫entender e escrever JSON. 262 00:11:52,620 --> 00:11:55,930 ‫Você provavelmente já percebeu que JSON se parece um pouco 263 00:11:55,930 --> 00:11:57,990 ‫com um objeto JavaScript normal, certo? 264 00:11:57,990 --> 00:12:00,510 ‫Com todos esses pares de valores-chave. 265 00:12:00,510 --> 00:12:04,020 ‫Existem, no entanto, algumas diferenças, e a mais importante 266 00:12:04,020 --> 00:12:06,470 ‫é que todas as teclas têm 267 00:12:06,470 --> 00:12:08,320 ‫de ser strings. 268 00:12:08,320 --> 00:12:10,960 ‫Também é muito comum que os valores sejam 269 00:12:10,960 --> 00:12:12,580 ‫strings, mas podem ser 270 00:12:12,580 --> 00:12:14,730 ‫outras coisas como números, valores verdadeiros ou 271 00:12:14,730 --> 00:12:17,440 ‫falsos, outro objeto ou mesmo matrizes de outros valores. 272 00:12:17,440 --> 00:12:20,690 ‫É bastante simples, na verdade. 273 00:12:20,690 --> 00:12:23,328 ‫E a partir deste exemplo, você pode ver 274 00:12:23,328 --> 00:12:25,790 ‫como um JSON típico pode se parecer. 275 00:12:25,790 --> 00:12:27,070 ‫Digamos que este 276 00:12:27,070 --> 00:12:30,883 ‫seja um dado que temos em nosso banco de dados para uma 277 00:12:31,890 --> 00:12:35,290 ‫solicitação GET a esta URL para o tour com I. D. de cinco. 278 00:12:35,290 --> 00:12:38,560 ‫Agora, poderíamos enviá-lo de volta assim para o cliente, mas 279 00:12:38,560 --> 00:12:41,440 ‫normalmente fazemos 280 00:12:41,440 --> 00:12:44,300 ‫alguma formatação de resposta simples antes de enviar. 281 00:12:44,300 --> 00:12:47,130 ‫Existem alguns padrões para isso e vamos usar um 282 00:12:47,130 --> 00:12:48,620 ‫muito simples chamado Jsend. 283 00:12:48,620 --> 00:12:50,880 ‫Simplesmente criamos um novo objeto e, 284 00:12:50,880 --> 00:12:54,570 ‫em seguida, adicionamos uma mensagem de status a ele para informar 285 00:12:54,570 --> 00:12:56,320 ‫ao cliente se a 286 00:12:56,320 --> 00:12:58,310 ‫solicitação foi bem-sucedida, falha ou 287 00:12:58,310 --> 00:13:00,740 ‫erro, e então colocamos nossos dados originais 288 00:13:00,740 --> 00:13:03,350 ‫em um novo objeto chamado Dados, certo? 289 00:13:03,350 --> 00:13:05,390 ‫E podemos desenvolver isso 290 00:13:05,390 --> 00:13:08,510 ‫um pouco mais, mas essa é realmente a maneira 291 00:13:08,510 --> 00:13:10,640 ‫mais simples de formatar com Jsend. 292 00:13:10,640 --> 00:13:12,020 ‫E, a propósito, agrupar os 293 00:13:12,020 --> 00:13:14,250 ‫dados em um objeto adicional, como fizemos aqui, 294 00:13:14,250 --> 00:13:15,240 ‫é chamado 295 00:13:15,240 --> 00:13:17,550 ‫de envelope e é uma prática comum para 296 00:13:17,550 --> 00:13:19,860 ‫mitigar alguns problemas de segurança e outros problemas. 297 00:13:19,860 --> 00:13:21,470 ‫Além disso, existem outros 298 00:13:21,470 --> 00:13:25,550 ‫padrões de formatação de resposta que você pode examinar, como Jsend: API 299 00:13:25,550 --> 00:13:27,200 ‫ou o protocolo Odata JSON. 300 00:13:27,200 --> 00:13:30,330 ‫Tudo bem e, finalmente, uma 301 00:13:30,330 --> 00:13:34,333 ‫API RESTful deve sempre ser sem estado. 302 00:13:35,800 --> 00:13:37,470 ‫Então, o que realmente significa sem estado? 303 00:13:37,470 --> 00:13:40,720 ‫Bem, em uma API RESTful sem estado, 304 00:13:40,720 --> 00:13:43,170 ‫todo o estado é tratado 305 00:13:43,170 --> 00:13:45,960 ‫no cliente e não no servidor. 306 00:13:45,960 --> 00:13:48,410 ‫E o estado simplesmente se refere a um dado no aplicativo 307 00:13:48,410 --> 00:13:50,120 ‫que pode mudar com o tempo. 308 00:13:50,120 --> 00:13:52,910 ‫Por exemplo, se um determinado usuário está logado 309 00:13:52,910 --> 00:13:55,750 ‫ou em uma página com uma lista com 310 00:13:55,750 --> 00:13:56,583 ‫várias 311 00:13:56,583 --> 00:13:58,720 ‫páginas, qual é a página atual. 312 00:13:58,720 --> 00:14:02,230 ‫Agora o fato de que o estado deve ser tratado 313 00:14:02,230 --> 00:14:04,150 ‫no cliente significa que cada 314 00:14:04,150 --> 00:14:06,170 ‫requisição deve conter todas as informações 315 00:14:06,170 --> 00:14:09,910 ‫que são necessárias para processar uma determinada requisição no servidor, certo? 316 00:14:09,910 --> 00:14:12,710 ‫Isso faz sentido? 317 00:14:12,710 --> 00:14:15,780 ‫Portanto, o servidor nunca deve ter que 318 00:14:15,780 --> 00:14:17,170 ‫se lembrar 319 00:14:17,170 --> 00:14:21,030 ‫da solicitação anterior para processar a solicitação atual. 320 00:14:21,030 --> 00:14:24,010 ‫Vamos pegar a lista com várias páginas como exemplo. 321 00:14:24,010 --> 00:14:25,906 ‫E digamos que seja recorrente 322 00:14:25,906 --> 00:14:29,670 ‫na página cinco e queira avançar para a página seis. 323 00:14:29,670 --> 00:14:32,980 ‫Portanto, poderíamos ter um endpoint simples chamado / tours / 324 00:14:32,980 --> 00:14:36,006 ‫nextPage e enviar uma solicitação a ele, certo? 325 00:14:36,006 --> 00:14:39,710 ‫Mas o servidor teria que descobrir qual é a 326 00:14:40,650 --> 00:14:43,400 ‫página atual e, com base nisso, enviar 327 00:14:43,400 --> 00:14:45,610 ‫a próxima página ao cliente. 328 00:14:45,610 --> 00:14:48,450 ‫Em outras palavras, o servidor teria que 329 00:14:48,450 --> 00:14:50,496 ‫se lembrar da solicitação anterior. 330 00:14:50,496 --> 00:14:51,730 ‫Teria que lidar 331 00:14:51,730 --> 00:14:54,950 ‫com o lado do servidor de estado e é exatamente 332 00:14:54,950 --> 00:14:57,640 ‫isso que queremos evitar nas APIs RESTful, ok? 333 00:14:57,640 --> 00:15:00,260 ‫Em vez disso, neste caso, devemos criar 334 00:15:00,260 --> 00:15:03,120 ‫um endpoint / tours / page e 335 00:15:03,120 --> 00:15:04,630 ‫colar o número 336 00:15:04,630 --> 00:15:07,550 ‫seis nele para solicitar a página número seis. 337 00:15:07,550 --> 00:15:09,410 ‫Dessa forma, iríamos indicar no cliente, 338 00:15:09,410 --> 00:15:11,850 ‫porque em um cliente, já saberíamos que estamos 339 00:15:11,850 --> 00:15:14,340 ‫na página cinco e então tudo o que precisamos 340 00:15:14,340 --> 00:15:15,410 ‫fazer é apenas 341 00:15:15,410 --> 00:15:18,320 ‫adicionar um e, em seguida, solicitar a página número seis. 342 00:15:18,320 --> 00:15:20,750 ‫Portanto, o servidor não precisa se lembrar 343 00:15:20,750 --> 00:15:22,750 ‫de nada neste caso. 344 00:15:22,750 --> 00:15:23,920 ‫Tudo o que precisa fazer é 345 00:15:23,920 --> 00:15:25,840 ‫enviar de volta os dados da página número seis, conforme solicitamos. 346 00:15:25,840 --> 00:15:27,940 ‫E, a propósito, apatridia e ausência 347 00:15:27,940 --> 00:15:30,840 ‫de estado, que é o oposto, são conceitos 348 00:15:30,840 --> 00:15:33,891 ‫muito importantes na ciência da computação e no design 349 00:15:33,891 --> 00:15:35,760 ‫de aplicativos em geral. 350 00:15:35,760 --> 00:15:38,560 ‫Portanto, é uma boa ideia realmente ter algum conhecimento do que é 351 00:15:38,560 --> 00:15:40,800 ‫uma API sem estado e como ela funciona. 352 00:15:40,800 --> 00:15:44,070 ‫Enfim, essa foi uma palestra enorme, mas 353 00:15:44,070 --> 00:15:47,331 ‫também uma das mais importantes. 354 00:15:47,331 --> 00:15:50,280 ‫Eu não posso enfatizar o suficiente e eu realmente 355 00:15:50,280 --> 00:15:52,670 ‫acho que você pode ver isso, certo? 356 00:15:52,670 --> 00:15:55,700 ‫De qualquer forma, vamos finalmente voltar ao nosso código.