‫Instrutor: Agora que sabemos o que é
‫Express, estamos quase prontos para começar a construir nossa API.
‫Mas antes de
‫fazermos isso, preciso falar rapidamente sobre APIs em um nível
‫superior e, mais importante,
‫apresentar a você a Arquitetura REST,
‫que é a arquitetura de API mais usada atualmente.
‫Dessa forma, saberemos realmente o que estamos construindo.
‫Portanto, é extremamente importante entender as coisas neste
‫vídeo antes de prosseguir, para que
‫possamos realmente saber o que estamos construindo ao
‫longo do resto do curso.
‫Em primeiro
‫lugar, API significa Interface de Programação de Aplicativo e,
‫em um nível muito
‫alto, é basicamente um software que pode
‫ser usado por outro software
‫para permitir que os aplicativos se comuniquem.
‫Na verdade, já falamos sobre
‫APIs antes, mais especificamente, APIs da web,
‫onde simplesmente construímos um aplicativo que envia
‫dados a um cliente sempre que uma solicitação chega.
‫Imagine que temos nosso aplicativo rodando em um servidor
‫e temos um cliente.
‫Então, na verdade, temos dois softwares
‫conversando, certo?
‫E esse é o tipo de API que construiremos neste curso.
‫E eu acho que é o tipo de API mais usado por aí.
‫Mas, na verdade, as APIs não são usadas apenas para enviar dados e
‫nem sempre estão relacionadas ao desenvolvimento web ou JavaScript.
‫O aplicativo na API pode significar
‫muitas coisas diferentes, desde que o
‫software seja relativamente independente.
‫Considere, por
‫exemplo, o Node File System ou os Módulos HTTP.
‫Podemos dizer que são pequenos softwares
‫e podemos
‫usá-los, podemos interagir com eles usando sua API.
‫Por
‫exemplo, quando usamos a função readfile do Módulo FS,
‫na verdade estamos usando a API FS.
‫E é por isso que você às vezes ouvirá o termo APIs de nó.
‫E isso geralmente se refere simplesmente aos módulos do nó central
‫com os quais podemos interagir.
‫Ou quando fazemos a manipulação do DOM no
‫navegador, não estamos realmente usando a linguagem JavaScript em si,
‫mas sim a API DOM que o navegador nos expõe, de modo que
‫nos dá acesso a ela.
‫Ou até mesmo outro exemplo,
‫digamos que criamos uma classe em qualquer linguagem de programação
‫como Java e, em seguida, adicionamos alguns métodos públicos
‫ou propriedades a ela.
‫Esses métodos serão então a API de cada
‫objeto criado a partir dessa classe,
‫pois estamos dando a outros softwares
‫a possibilidade de interagir com nosso software inicial, os
‫objetos, neste caso.
‫Veja, API tem um significado mais amplo do que
‫apenas construir APIs da web.
‫Tudo bem? De qualquer forma, uma API da web
‫é o mais importante para nós no contexto da observação.
‫Vamos agora dar uma olhada na Arquitetura REST
‫para construir APIs.
‫REST, que significa Representational States Transfer, é basicamente uma forma
‫de construir APIs da web de uma forma lógica,
‫tornando-as fáceis de consumir
‫porque lembre-se, nós construímos uma API para nós
‫mesmos ou para outros consumirem, ok?
‫Queremos tornar o processo de uso da API o mais
‫suave possível para o usuário.
‫Agora, para construir APIs
‫RESTful, o que significa APIs seguindo a Arquitetura
‫REST, precisamos apenas seguir alguns princípios.
‫Primeiro, precisamos separar nossa API em recursos lógicos.
‫Esses recursos devem então ser expostos, o
‫que significa que devem ser
‫disponibilizados por meio de URLs estruturados e baseados em recursos.
‫Para realizar diferentes ações
‫nos dados, como ler, criar ou excluir dados,
‫a API deve usar os métodos HTP corretos e não o URL.
‫Agora, os dados que realmente enviamos de volta ao
‫cliente ou que recebemos do cliente
‫geralmente devem usar o formato de dados JSON,
‫onde algum padrão de formatação se aplica a ele.
‫Finalmente, outro princípio importante das APIs REST é
‫que elas devem ser sem estado.
‫Portanto, esta é uma visão geral muito ampla.
‫Agora vamos começar a falar sobre
‫esses princípios um por um, começando com recursos e usando
‫a API Nators que iremos construir neste
‫curso como um exemplo aqui.
‫A abstração chave das informações no REST é um recurso
‫e, portanto, todos os dados
‫que queremos compartilhar na API devem ser divididos em recursos lógicos.
‫Agora, o que realmente é um recurso?
‫Bem, no contexto do
‫REST, é um objeto ou uma representação de algo
‫que possui alguns dados associados a ele.
‫Por
‫exemplo, passeios, ou usuários, ou comentários no
‫caso do exemplo que estamos seguindo.
‫Então, basicamente, qualquer informação que possa ser nomeada
‫pode ser um recurso, certo?
‫Só precisa ser um nome, não um verbo.
‫Agora, precisamos expor,
‫o que significa disponibilizar, os
‫dados usando algumas URLs estruturadas para as quais
‫o cliente pode enviar uma solicitação.
‫Por exemplo, algo assim.
‫Todo esse endereço é chamado de URL
‫e este / addNewTour é chamado de endpoint de API.
‫Nossa API terá muitos endpoints diferentes, assim
‫como estes endpoints fictícios que tenho aqui, cada
‫um dos quais enviará dados diferentes de volta ao
‫cliente ou também executará ações diferentes.
‫Agora, há realmente algo muito
‫errado com esses endpoints aqui porque eles realmente não
‫seguem a terceira regra que diz que
‫devemos usar apenas os métodos HTTP para realizar ações nos dados.
‫Portanto, os endpoints devem conter apenas nossos recursos e
‫não as ações que podem ser executadas
‫neles, pois sua manutenção se tornará rapidamente um pesadelo.
‫Como devemos usar esses métodos HTTP na prática?
‫Bem, vamos ver como esses
‫pontos de extremidade devem realmente parecer começando com / getTour.
‫Portanto, este ponto de extremidade / getTour é para obter dados sobre um passeio.
‫Portanto, devemos simplesmente nomear o endpoint / tours e enviar
‫os dados sempre que uma solicitação get for
‫feita para esse endpoint.
‫Em outras
‫palavras, quando um cliente usa um método GET
‫HTTP para acessar o terminal.
‫E assim,
‫só temos recursos no endpoint
‫ou na URL e nenhum verbo porque o
‫verbo agora está no método HTTP, certo?
‫E, a
‫propósito, é uma prática comum sempre usar o nome
‫do recurso no plural, por isso tenho / tours aqui e não / tour.
‫Agora, a convenção é que, ao chamar esse
‫endpoint, recebemos todos os passeios que estão em um banco de dados, certo?
‫Mas se quisermos apenas a turnê com um I. D. digamos sete, adicionamos
‫esse sete após outra barra ou em uma consulta de pesquisa.
‫Ou também pode ser o nome de um passeio em vez de I. D. ou algum outro identificador exclusivo.
‫O detalhe realmente não importa neste ponto, certo?
‫Posteriormente, mostrarei como é fácil
‫implementar esse tipo de lógica com o Express porque
‫é aqui que o Express realmente se destaca.
‫O primeiro método HTTP ou
‫verbo ao qual podemos responder é GET e é
‫usado para realizar a operação Read nos dados.
‫Próxima parada, se o cliente
‫deseja criar um novo recurso em nosso banco de
‫dados, neste exemplo, um
‫novo tour, deve-se utilizar o método POST.
‫Portanto, aprendemos anteriormente que uma solicitação
‫POST pode ser usada para enviar dados
‫ao servidor e, portanto, faz sentido usar POST para
‫criar novos recursos, certo?
‫Agora, neste caso, geralmente não. D. será enviado porque
‫o servidor deve descobrir automaticamente o
‫I. D. para o novo recurso.
‫De qualquer forma, o que é realmente importante observar aqui é como o nome do terminal é exatamente
‫o mesmo nome de antes.
‫A única diferença é realmente
‫o método HTP usado para a solicitação.
‫Se o endpoint / tours for acessado com GET,
‫enviamos os dados ao cliente.
‫Mas se o mesmo endpoint for acessado com POST, esperamos
‫que os dados cheguem
‫com uma solicitação, para que possamos criar
‫um novo recurso no lado do servidor.
‫Portanto, essa é realmente a beleza de usar apenas métodos HTTP em vez
‫de mexer com verbos em nomes de terminais.
‫Novamente, isso realmente se tornaria incontrolável muito rápido.
‫Tudo bem, em seguida, também
‫deve haver a capacidade de atualizar recursos.
‫E para isso, uma solicitação PUT
‫ou PATCH deve ser feita ao
‫terminal.
‫A diferença entre eles é que com
‫PUT, o cliente deve enviar todo
‫o objeto atualizado, enquanto que com
‫PATCH, ele deve enviar apenas a parte do objeto que
‫foi alterada.
‫Mas ambos têm a capacidade de
‫enviar dados ao servidor.
‫Um pouco como o POST, na verdade, mas com uma intenção diferente.
‫Então POST é
‫para criar um novo recurso, enquanto PUT ou PATCH são
‫usados para atualizar um recurso existente
‫e então faz toda a diferença.
‫E por fim, para o recurso
‫de lixo, existe o método DELETE HTTP.
‫Novamente, o I. D. ou algum outro identificador exclusivo do
‫recurso a ser excluído deve fazer parte da
‫URL.
‫Agora, normalmente, para poder realmente
‫realizar esse tipo
‫de solicitação, o cliente deve estar autenticado.
‫Então, basicamente, faça login em seu aplicativo, certo?
‫Mas esse é, obviamente, um assunto para muito mais tarde.
‫Portanto, esses são os cinco métodos HTTP
‫aos quais podemos e devemos responder
‫ao construir nossas APIs RESTful para que
‫o cliente possa realizar
‫as quatro operações CRUD básicas.
‫Portanto, CRUD significa Criar, Ler, Atualizar e Excluir.
‫E você verá esse termo o
‫tempo todo relacionado a APIs e coisas de banco de dados.
‫E você vê que esses métodos
‫HTTP mapeiam muito bem para as operações CRUD básicas.
‫Agora, pode haver ações
‫que não são CRUD e, nesse caso, só
‫precisamos ser criativos com nossas entradas.
‫Por exemplo, um
‫login ou uma operação de pesquisa, eles não estão
‫realmente relacionados
‫a um recurso específico e também não
‫são operações CRUD, mas ainda podemos criar pontos de extremidade para eles.
‫Por exemplo, como / login ou / search.
‫Mas falaremos mais sobre esses casos mais tarde na prática.
‫E só para terminar esta parte agora, lembre-se
‫de que tínhamos dois outros nomes de endpoint malucos
‫no último slide que
‫envolviam dois recursos ao mesmo tempo, certo?
‫E isso também não é nenhum problema com REST.
‫Portanto, / getToursByUser pode
‫ser simplesmente traduzido para / users
‫/ tours, neste caso, o usuário número três.
‫Portanto, este ponto de extremidade específico aqui pode
‫enviar dados sobre todos os passeios que
‫o usuário número três reservou.
‫Faz sentido?
‫Ou, no caso de exclusão, pode haver uma
‫solicitação de
‫exclusão para o mesmo endpoint ou
‫muito semelhante, solicitando que o tour número nove seja
‫excluído do usuário número três, certo?
‫Portanto, existem muitas possibilidades
‫de combinar recursos como este.
‫Mas é claro, não precisamos implementar todas
‫essas combinações em nossa API.
‫Implementamos apenas o que faz
‫sentido no caso de nossa aplicação e do
‫cliente que deseja consumir nossa API.
‫Portanto, é assim que
‫usamos métodos HTTP para construir URLs amigáveis e
‫bem estruturados que são fáceis e lógicos de consumir para o cliente.
‫Agora, sobre os dados que o cliente realmente
‫recebe, ou que o servidor recebe
‫do cliente, normalmente usamos o formato de dados JSON.
‫Então, vamos aprender brevemente o que JSON realmente é
‫e como formatar nossas respostas de API.
‫JSON é um formato de intercâmbio de
‫dados muito leve, muito
‫usado por APIs da web codificadas em qualquer linguagem de programação.
‫Portanto, não está relacionado a um JavaScript.
‫E é tão amplamente usado hoje
‫porque é muito fácil para humanos e computadores
‫entender e escrever JSON.
‫Você provavelmente já percebeu que JSON se parece um pouco
‫com um objeto JavaScript normal, certo?
‫Com todos esses pares de valores-chave.
‫Existem, no entanto, algumas diferenças, e a mais importante
‫é que todas as teclas têm
‫de ser strings.
‫Também é muito comum que os valores sejam
‫strings, mas podem ser
‫outras coisas como números, valores verdadeiros ou
‫falsos, outro objeto ou mesmo matrizes de outros valores.
‫É bastante simples, na verdade.
‫E a partir deste exemplo, você pode ver
‫como um JSON típico pode se parecer.
‫Digamos que este
‫seja um dado que temos em nosso banco de dados para uma
‫solicitação GET a esta URL para o tour com I. D. de cinco.
‫Agora, poderíamos enviá-lo de volta assim para o cliente, mas
‫normalmente fazemos
‫alguma formatação de resposta simples antes de enviar.
‫Existem alguns padrões para isso e vamos usar um
‫muito simples chamado Jsend.
‫Simplesmente criamos um novo objeto e,
‫em seguida, adicionamos uma mensagem de status a ele para informar
‫ao cliente se a
‫solicitação foi bem-sucedida, falha ou
‫erro, e então colocamos nossos dados originais
‫em um novo objeto chamado Dados, certo?
‫E podemos desenvolver isso
‫um pouco mais, mas essa é realmente a maneira
‫mais simples de formatar com Jsend.
‫E, a propósito, agrupar os
‫dados em um objeto adicional, como fizemos aqui,
‫é chamado
‫de envelope e é uma prática comum para
‫mitigar alguns problemas de segurança e outros problemas.
‫Além disso, existem outros
‫padrões de formatação de resposta que você pode examinar, como Jsend: API
‫ou o protocolo Odata JSON.
‫Tudo bem e, finalmente, uma
‫API RESTful deve sempre ser sem estado.
‫Então, o que realmente significa sem estado?
‫Bem, em uma API RESTful sem estado,
‫todo o estado é tratado
‫no cliente e não no servidor.
‫E o estado simplesmente se refere a um dado no aplicativo
‫que pode mudar com o tempo.
‫Por exemplo, se um determinado usuário está logado
‫ou em uma página com uma lista com
‫várias
‫páginas, qual é a página atual.
‫Agora o fato de que o estado deve ser tratado
‫no cliente significa que cada
‫requisição deve conter todas as informações
‫que são necessárias para processar uma determinada requisição no servidor, certo?
‫Isso faz sentido?
‫Portanto, o servidor nunca deve ter que
‫se lembrar
‫da solicitação anterior para processar a solicitação atual.
‫Vamos pegar a lista com várias páginas como exemplo.
‫E digamos que seja recorrente
‫na página cinco e queira avançar para a página seis.
‫Portanto, poderíamos ter um endpoint simples chamado / tours /
‫nextPage e enviar uma solicitação a ele, certo?
‫Mas o servidor teria que descobrir qual é a
‫página atual e, com base nisso, enviar
‫a próxima página ao cliente.
‫Em outras palavras, o servidor teria que
‫se lembrar da solicitação anterior.
‫Teria que lidar
‫com o lado do servidor de estado e é exatamente
‫isso que queremos evitar nas APIs RESTful, ok?
‫Em vez disso, neste caso, devemos criar
‫um endpoint / tours / page e
‫colar o número
‫seis nele para solicitar a página número seis.
‫Dessa forma, iríamos indicar no cliente,
‫porque em um cliente, já saberíamos que estamos
‫na página cinco e então tudo o que precisamos
‫fazer é apenas
‫adicionar um e, em seguida, solicitar a página número seis.
‫Portanto, o servidor não precisa se lembrar
‫de nada neste caso.
‫Tudo o que precisa fazer é
‫enviar de volta os dados da página número seis, conforme solicitamos.
‫E, a propósito, apatridia e ausência
‫de estado, que é o oposto, são conceitos
‫muito importantes na ciência da computação e no design
‫de aplicativos em geral.
‫Portanto, é uma boa ideia realmente ter algum conhecimento do que é
‫uma API sem estado e como ela funciona.
‫Enfim, essa foi uma palestra enorme, mas
‫também uma das mais importantes.
‫Eu não posso enfatizar o suficiente e eu realmente
‫acho que você pode ver isso, certo?
‫De qualquer forma, vamos finalmente voltar ao nosso código.