Tutorial CRUD em Node.js com driver nativo do MongoDB – Parte 2

O tutorial de hoje é uma continuação de um outro tutorial aqui do blog, muito acessado aliás, onde ensino como fazer um sistema de cadastro bem simples em Node.js, usando o web framework ExpressJS e o banco de dados MongoDB. Ou seja, o famoso CRUD.

Nesta segunda parte, parto para um conceitos mais avançados em cima do mesmo projeto: paginação de resultados.

Para conseguir acompanhar todos os códigos, é importante que você tenha realizado a parte anterior ou pelo menos baixe os códigos-fonte que se encontram no formulário ao final do tutorial anterior.

Vamos lá!

Atenção, este mesmo tutorial está disponível em videoaula em meu curso de Node.js e MongoDB.

Paginação com Node.js e MongoDB

Nossa aplicação simplesmente lista todos os documentos da nossa coleção no MongoDB, sem qualquer distinção. Nas primeiras duas etapas deste tutorial vamos restringir isso, primeiramente através de uma paginação de resultados e depois através de uma busca.

Conforme trato em detalhes no artigo Tutorial MongoDB para iniciantes em NoSQL: Parte 2, fazemos paginação no MongoDB usando as funções skip e limit de maneira apropriada.

A função skip indica ao MongoDB que deve-se ignorar um número x de resultados da consulta na hora de retornar do servidor de banco. Já a função limit diz ao Mongo que ele deve retornar apenas um número limitado de documentos, independente se a busca retornaria mais elementos normalmente. Ambas funções devem ser usadas após um find, como veremos a seguir.

A lógica para criar paginação é bem simples: determine um tamanho de página, por exemplo 10 elementos, descubra o total de elementos que a consulta retornaria, por exemplo 21 elementos, e depois dividida o total pelo tamanho de página, arredondando sempre pra cima. Pronto, você tem a quantidade de páginas para aquela consulta! Neste exemplo de 21 elementos com uma paginação de tamanho 10, serão 3 páginas, sendo que as duas primeiras terão exatamente 10 elementos e a última apenas 1.

Entendeu?

Para determinar o tamanho de página ideal para seu sistema você tem de levar em consideração a performance da sua aplicação e a experiência do seu usuário. Muitas páginas com poucos elementos é fácil do banco retornar, mas ruim pro usuário ficar navegando. Poucas páginas com muitos elementos é o oposto e o segredo está no equilíbrio. Neste exemplo, ficaremos com tamanho 10 mesmo, para fins de teste.

Paginação de Resultados em Node.js

Então nosso primeiro passo será modificar uma function já existente no módulo db.js da nossa aplicação para que ela retorne os resultados de maneira paginada, como abaixo:

Note que comecei definindo uma constante com o tamanho das páginas sendo 10. Depois, adicionei um novo parâmetro na função findAll que espera a página que a aplicação deseja apresentar. Este parâmetro eu uso para calcular o skip, ou seja, quantos elementos da consulta eu devo ignorar. Se a página for a primeira, o skip será zero e serão mostrados os primeiros 10 elementos. Se a página for a segunda, o skip será 10 pela fórmula e serão mostrados os elementos das posições 11 a 20 (ordinal, ou 10 a 19 considerando um array zero-based).

Agora vamos modificar onde esta função findAll é chamada: na pasta routes, módulo index.js, que vamos modificar levemente a rota GET padrão apenas para adicionar o parâmetro página nela:

Note que coloquei o parâmetro no path como sendo opcional (?) e se ele não tiver sido passado na URL, será atribuído como um. Esse truque do || para atribuir um valor default eu ensinei no artigo 15 Dicas de JavaScript, lembra?

Certifique-se de que esta rota seja a última do arquivo index.js, logo antes do module.exports!

Como as rotas são testadas da primeira até a última para ver qual que processará a requisição deixaremos esta pro final para não interferir nas demais avaliações.

Agora execute a aplicação e teste a index passando a página na URL, como abaixo. Note que tive de adicionar muitos customers no banco de dados para podermos ter alguma paginação.

Paginação funcionando via URL
Paginação funcionando via URL

Mas obviamente não faremos nosso usuário ter de mudar parâmetros na URL para acessar as páginas, certo?

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Paginação de resultados com ExpressJs e EJS

Para que o usuário saiba quantas páginas existem e para que consiga acessar as mesmas, vamos ter de criar uma lógica para construir o HTML de paginação no frontend e uma lógica para retornar algumas informações importantes no backend.

Vamos começar pelo backend que é mais a minha praia. XD

Abra seu arquivo db.js novamente e vamos criar uma function countAll que executa o callback passado por parâmetro retornando um erro (opcional) e a quantidade de documentos na coleção customers. Note que atualizei o module.exports com a nova função e também exportando a constante com o tamanho de página.

Agora na routes/index.js, mais especificamente no nosso GET default (a última rota do arquivo), vamos ajustar as chamadas para construir o model com as informações que precisaremos no frontend EJS:

Note que tive de encadear as duas chamadas de banco uma dentro da outra, para garantir que a página somente será renderizada quando tivermos tanto os documentos da consulta quanto a quantidade total de documentos na coleção. Esse é justamente o ponto fraco do uso de callbacks, o chamado Callback Hell, mas falarei disso em outro artigo.

A cereja do bolo fica para o cálculo de quantidade de páginas que fizemos ali, dividindo o total de documentos pelo tamanho da página, usando a constante existente no módulo db.js. Ah sim, você não esqueceu de expor esta constante no module.exports, certo?

Agora que nosso model está completo, vamos mexer na index.ejs, nossa view inicial da aplicação para renderizar a quantidade total de elementos e o HTML de paginação para que o usuário possa navegar entre as páginas:

Esse código eu coloquei bem no final do arquivo EJS, onde antes ficava apenas o botão de Cadastrar novo cliente. Se você fez tudo certo até aqui, quando testar novamente você deve ver o seguinte resultado na interface da listagem:

Paginação funcionando
Paginação funcionando

Melhorando usabilidade da paginação

Para encerrar este tutorial, vamos adicionar uma perfumaria para melhorar ainda mais a usabilidade desta página: a página atual não deve ter link, apenas as demais páginas, assim, o usuário saberá em que página ele se encontra atualmente.

Vamos iniciar ajustando o model retornado no nosso index.js para informar também a página atual solicitada pelo usuário:

Note que a mudança foi bem sutil, apenas uma nova propriedade no JSON ‘pagina’.

Para fazer a lógica necessário para que o HTML ora tenha link, ora não tenha, basta adicionar um if na lógica de construção do nosso EJS usando a informação da página oriunda do model:

Ou seja, se a variável de iteração ‘i’ for diferente da página atual, escreve um link HTML na tela, caso contrário, escreve apenas o número da página. Visualmente falando temos a imagem abaixo como referência:

Indicando a página atual
Indicando a página atual

Note como ficou evidente que estamos na página 2, pois não tem link pra ela!

Outras melhorias poderiam incluir legendas quando se passa o mouse sobre as páginas, links de próxima página e página anterior, lógica para quando tivermos muitas páginas (e se tiver 100 páginas, como ficará a tela?) e até mesmo informação textual de que você está vendo os itens x a y da página z.

Mas…isso fica para você pensar meu amigo ou minha amiga! 🙂

Até o próximo post!

Gostou do tutorial? Quer aprender ainda mais sobre Node.js, ExpressJS, EJS e MongoDB comigo? Conheça meu curso de Nodejs e MongoDB clicando no banner abaixo!

Curso Node.js e MongoDB
Curso Node.js e MongoDB

Autenticação em Node.js com Passport – Parte 3

Este artigo é uma continuação da parte 2 do meu tutorial de autenticação em Node.js usando a biblioteca Passport. Nessa terceira parte veremos como fazer um recurso bem simples de recuperação de senha via email e de logout do usuário autenticado.

Caso você deseje ver este artigo em vídeoaula, saiba que ela está disponível em meu curso online de Node.js e MongoDB.

Vamos lá!

Criando a recuperação de senha

Agora a próxima parte é a de recuperação de senha. Lembra que deixamos um link pra isso lá na tela de login?

Vamos começar criando uma nova view, a views/forgot.ejs, com um formulário bem simples que pede a confirmação de seu email para envio de uma nova senha:

E para que essa tela seja acessível, vamos criar uma nova rota GET em routes/users.js:

Rodando sua aplicação e acessando no navegador, já deve ser possível navegar até esta página usando o link na tela de login:

Esqueceu a senha
Esqueceu a senha

Para fazer funcionar este formulário, vamos começar criando duas funções em nosso arquivo db.js: uma que busca um usuário pelo seu email e outra que muda a senha de um usuário:

A primeira função é bem simples, um findOne por email, que executa um callback após encontrar (ou não) o usuário. A segunda recebe uma senha, criptografa ela e sobrescreve o hash de senha do usuário cujo id foi passado por parâmetro. O module.exports no final do db.js também foi atualizado de acordo.

Note que não estou criando as devidas validações em nenhum formulário para os artigos não ficarem gigantescos. Nem de campos obrigatórios, nem validações de regras de negócio como não permitir usuários e emails duplicados. Tenha em mente que você deverá implementar essas questões se for usar esses códigos em produção.

Antes de sairmos fazendo a rota POST, vamos criar um arquivo utils.js na raiz do nosso projeto e colocar dentro dele uma função de geração de senha aleatória:

Esta função é bem simples e talvez você até queira usar alguma mais avançada. Aqui eu crio e retorno uma senha aleatória de 10 caracteres alfanuméricos (maiúsculas, minúsculas e números).

Agora que temos estas funções podemos criar a nossa rota POST que vai receber os dados do formulário de “esqueci minha senha”. Abra o arquivo routes/users.js e crie a nova rota:

Aqui começamos com o findUser que criamos anteriormente, que busca usuário por email. Caso não encontre, vamos jogar o usuário para a tela de login mesmo assim, embora você possa pensar em algo mais criativo para fazer.

Caso encontre, mandamos gerar uma nova senha usando a função que criei há pouco e uso o changePassword para mudar a senha do usuário que possui o email especificado (em um sistema de produção, para evitar problemas, além do email, peça alguma informação pessoal do usuário para confirmar esse processo de troca de senha). Por fim, um email é enviado com a senha que acabou de ser gerada, como na imagem abaixo.

Nova senha
Nova senha

Se você tentar se autenticar com a senha antiga, notará que ela não funciona mais, somente a nova.

É uma boa prática guardar o hash das últimas senhas do usuário e não deixar que ele use senhas antigas (mesmo senhas aleatórias podem conflitar ocasionalmente). Outra boa prática seria no primeiro login com a nova senha ele ser solicitado a cadastrar uma senha pessoal ao invés dessa aleatória. Enfim, sempre há margem para melhorar quando o assunto é segurança.

Logout

Até o momento nos preocupamos em autenticar os usuários que desejam entrar no sistema. Mas e os usuários que desejam sair? Como podemos implementar uma funcionalidade de logout na nossa aplicação?

Muito simples!

Na view index.ejs (ou onde quiser), adicione um form HTML com um botão que fará um post em uma rota logoff, como abaixo:

Agora é hora de criarmos esta rota, o que devemos fazer em routes/login.js, nosso módulo de rotas de autenticação. Adicione a nova rota abaixo:

Note que o objeto req (request) possui um método logOut(). Isso porque foi injetada esta função nele através do Passport. Se você executar esta aplicação agora, se autenticar e depois clicar no botão de logoff, não apenas irá voltar para a tela de login, mas não conseguirá acessar a área logada até que se autentique novamente.

Teste e verá que funciona perfeitamente!

Não é exatamente uma parte 4, mas este tutorial sobre JSON Web Token ajuda a preencher a lacuna de autorização (visto que até o momento vimos apenas autenticação). No caso de estar utilizando arquitetura microservices, é uma boa colocar sua autenticação vinculada a regras de autorização no seu API Gateway.

Este artigo tem uma versão em videoaula em uma das aulas do meu curso de Nodejs e MongoDB que você confere clicando no banner abaixo.

Curso Node.js e MongoDB
Curso Node.js e MongoDB

HTTP para programadores Node.js

Você já se perguntou o que acontece quando você digita uma URL no navegador, do início ao fim da requisição?

Neste artigo, eu vou falar não apenas sobre como funciona o HTTP/1.1, mas também como o Node.js trabalha com este importantíssimo protocolo da web. Assim, mesmo que você não programe em Node, este artigo serve de referência para o protocolo HTTP em si. Caso programe em Node, vai te dar uma boa base do módulo http do Node, um dos mais essenciais.

Veremos neste artigo:

  1. O protocolo HTTP
  2. O módulo http do Node.js
  3. Construindo um servidor HTTP em Node
  4. Fazendo requisições HTTP em Node

Vamos lá!

O protocolo HTTP

Se você já fez uma entrevista para uma vaga de programador web provavelmente já lhe perguntaram “o que acontece quando você digita algo na caixa de busca do Google e aperta Enter?”

É uma pergunta muito popular pois os entrevistadores técnicos querem entender se você consegue explicar alguns dos conceitos básicos e se você tem alguma ideia de como a Internet realmente funciona.

Neste tópico eu vou mostrar pra você o que acontece quando você digita um endereço na barra do navegador e aperta Enter. É um tópico muito interessante e útil, pois é uma tecnologia muito presente, que raramente muda e que permite a existência de um complexo e vasto ecossistema que é a Internet.

Então começando a explicação, imagine que você digitou uma URL no navegador e apertou Enter. É aqui que nossa aventura começa…

DNS Lookup

O browser começa o DNS Lookup para obter o endereço IP do servidor. O nome do domínio é um apelido para nós humanos lembrarmos mais facilmente, mas a internet é organizada de maneira que os computadores trabalham apenas com os endereços IP para saber onde estão os computadores em um formato numérico como 222.324.3.1 (IPv4).

O primeiro lugar onde o IP é procurado pelo browser é no cache de DNS da sua máquina. Se não estiver lá, ele vai procurar no arquivos hosts (que varia de local conforme seu SO). Se não encontrar nada lá, a última alternativa é perguntar ao servidor de DNS.

O endereço do servidor de DNS fica salvo nas preferências do sistema, na parte de redes. Dois populares servidores de DNS são:

  • 8.8.8.8: o servidor de DNS do Google;
  • 1.1.1.1: o servidor de DNS da CloudFlare;

O mais comum é que as pessoas usem o servidor de DNS fornecido pelo seu provedor de Internet.

E quando esse servidor de DNS não possui a resposta para a requisição realizada? Aí é que entram os servidores raiz de DNS, 13 pontos de conexão ao redor do mundo que, ao invés de terem todos os endereços do mundo cadastrados, possuem o endereço dos servidores top-level.

Um servidor top-level é aquele responsável por uma extensão TLD (top-level domain) como .com, .br, .org, etc. O servidor top-level para os domínios .br, por exemplo, possui cadastrado todos os endereços de domínios terminados em .br.

Note que neste servidores existem caches. Conforme vão sendo feitas perguntas que eles não conhecem a resposta (i.e. domínios que eles não saibam o IP) eles descobrem onde fica perguntando uns aos outros e depois armazenam em seus caches locais, para que na próxima requisição seja mais rápido dar a resposta.

Mas ok, o processo de DNS lookup descobriu o IP da máquina onde está a URL que você está querendo acessar. Isso porque todos os domínios de Internet devem ser adquiridos junto a vendedores certificados, que possuem Name Servers online 24x7x365 (o ano inteiro, todos os dias, o tempo todo). Quando você compra um domínio, você recebe o endereço dos seus Name Servers, que são sempre mais de um para garantir alta disponibilidade, como por exemplo:

  • ns1.dreamhost.com
  • ns2.dreamhost.com
  • ns3.dreamhost.com

Inicia-se a procura pela máquina que queremos acessar no primeiro NS e somente são utilizados os outros no caso do primeiro não estar online. Mas enfim, nossa jornada de DNS Lookup termina aqui, acabamos de encontrar a máquina onde o site está hospedado.

DNS Lookup
DNS Lookup

Conexão e Requisição

Uma vez que temos o endereço IP da máquina correta, o browser pode se conectar na mesma para podermos enviar as requisições.

A requisição é um documento de texto estruturado de uma maneira específica conforme determinada pelo protocolo de comunicação. Ela é composta de três partes:

  • a linha de requisição
  • o cabeçalho de requisição
  • o corpo de requisição

A linha de requisição, que é obviamente uma única linha, possui:

  • o método HTTP
  • o local do recurso a ser acessado
  • a versão do protocolo

Por exemplo:

O cabeçalho da requisição é composto e pares chave-valor que definem algumas propriedades da requisição. Existem dois deles que são obrigatórios: Host e Connection, enquanto que todos os demais são opcionais.

Exemplo:

O Host indica o nome do domínio que você quer acessar, enquanto que Connection indica se queremos que a conexão seja fechada ou se mantenha aberta após a requisição.

Alguns outros cabeçalhos muito comuns são:

  • Origin
  • Accept
  • Accept-Encoding
  • Cookie
  • Cache-Control
  • Dnt

Mas existem muitos outros. O cabeçalho da requisição termina com uma linha em branco.

Já o corpo da requisição é opcional, não sendo utilizados em requisições GET, por exemplo, mas muito utilizado em requisições POST e alguns outros verbos, além de poder conter dados em vários formatos como JSON.

Como estamos em um cenário de acesso a uma URL, ou seja, um GET, ignoraremos o corpo por enquanto.

A resposta

Uma vez que a requisição é enviada, o servidor processa ela e envia de volta uma resposta. A resposta começa com o código de status e a mensagem de status. Se a requisição foi bem sucedida e retornar um 200, ela começará com um:

Mas as requisições podem ser respondidas com diferentes códigos e status, como estes:

Logo após, a resposta possui uma lista de cabeçalhos HTTP e o corpo da resposta, que no caso de acessar uma página de um site, será um documento HTML.

Analisando o HTML

Uma vez que o navegador obtenha o HTML do corpo da resposta e inicie a sua análise, ele irá repetir o mesmo processo completo (do DNS lookup até receber o arquivo) para cada um dos recursos presentes na página HTML como:

  • arquivos CSS
  • imagens
  • ícones
  • arquivos JS

E aí inicia o processo de renderização da página conforme as regras de todos estes arquivos juntos na estrutura HTML.

É importante entender que, apesar do exemplo ter sido em cima de HTML, que ele é o mesmo para qualquer recurso na web.

O módulo HTTP do Node.js

O módulo http do Node.js fornece funções úteis e classes para construir um servidor HTTP. Ele é um módulo-chave para os recursos de rede do Node.

Ele pode ser facilmente incluído em um módulo Node.js usando:

O objeto http declarado ali possui algumas propriedades e métodos, além e algumas classes.

http.METHODS

Esta propriedade lista todos os métodos HTTP suportados:

http.STATUS_CODES

Esta propriedade lista todos os códigos de status HTTP e sua descrição:

http.createServer()

Retorna uma nova instância da classe http.Server e seu uso é muito simples:

http.request()

Realiza uma requisição HTTP para um servidor, criando uma instância da classe http.ClientRequest.

http.get()

Similar ao http.request(), mas automaticamente define o método HTTP como GET e já finaliza a requisição com req.end() automaticamente.

O módulo HTTP também fornece cinco classes:

  • http.Agent
  • http.ClientRequest
  • http.Server
  • http.ServerResponde
  • http.IncomingMessage

Um objeto http.ClientRequest, por exemplo, é criado quando chamamos http.request() ou http.get(). Quando uma resposta é recebida o evento response é chamado com a resposta, passando uma instância de http.IncomingMessage como argumento.

Os dados retornados por uma resposta pode ser lido de duas maneiras:

  • você pode chamar o método response.read()
  • no event handler response você pode configurar um listener para o evento data, assim você pode receber os dados em formato de stream (bytes)

Já a classe http.Server é comumente instanciada e retornada quando criamos um novo servidor usando http.createServer(). Uma vez que você tenha um objeto server, você pode acessar seus métodos:

  • close() que encerra as atividades do servidor, não aceitando mais novas requisições;
  • listen() que inicia o servidor HTTP e espera novas conexões;

A classe http.ServerResponse é muito utilizada como argumento nos callbacks que tratam a resposta de requisições, a famosa variável ‘res’ presente em muitos callbacks, como abaixo:

É importante sempre salientar que após utilizarmos o objeto res devemos chamar o método end() para fechar a resposta e enviar a mesma para o cliente que fez a requisição.

Objetos res/response possuem alguns métodos para interagir com os cabeçalhos HTTP:

  • getHeadernames() traz a lista de nomes dos header presentes na resposta;
  • getHeaders() traz uma cópia dos headers presentes;
  • setHeader(‘nome’, valor) altera o valor de um header;
  • getHeader(‘nome’) retorna o valor de um header;
  • removeHeader(‘nome’) remove um header;
  • hasHeader(‘nome’) retorna true se a response possui este header;
  • headersSent() retorna true se os headers já foram enviados ao cliente;

Depois de fazer as alterações que desejar nos cabeçalhos do response, você pode enviá-los ao cliente usando response.writeHead(), que aceita o statusCode como o primeiro parâmetro, a mensagem opcional e os cabeçalhos.

Ok, mas nem só de cabeçalhos vive a resposta, certo? Para enviar dados ao cliente no corpo da requisição, você usa write(). Ele vai enviar dados bufferizados para a stream de resposta.

E por fim, a classe http.IncomingMessage é criada nas requisições. Mostrarei ela na prática mais à frente.

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Construindo um servidor HTTP em Node

Um servidor web HTTP para fazer um Olá Mundo é algo muito simples e popularmente conhecido na Internet. Você pode copiar o código abaixo e colar em um arquivo de texto com extensão ‘.js’:

Analisando linha por linha, temos:

  • inicialização do objeto HTTP;
  • definição da porta que o servidor irá esperar requisições;
  • criação do servidor e definição do callback que irá tratar cada requisição (objeto http.IncomingMessage);
  • dentro do callback modificamos a resposta (objeto http.ServerResponse) para retornar o status 200 (ok) e definir o cabeçalho como sendo texto e o HTML como sendo apenas ‘Olá Mundo!’ (fechando a resposta também);
  • e por fim, iniciamos a execução do servidor na porta especificada, definindo o callback que vai executar quando o servidor começar a funcionar;

Depois, para executar (considerando que você já tenha instalado o Node.js na sua máquina), basta abrir o terminal de linha de comando, navegar até a pasta onde você salvou o arquivo com ‘cd’ e depois rodar:

Se tudo funcionar, uma mensagem irá aparecer no console indicando que o servidor está funcionando. Se você acessar no navegador o endereço localhost:3000 você receberá como retorno um Olá Mundo muito simples, mas funcional (ignore o problema de encoding, por favor).

HTTP Server
HTTP Server

Fazendo requisições HTTP com Node

Nesta seção veremos como fazer requisições HTTP com Node.js. Na verdade usarei HTTPS nestes exemplos, que é o mesmo protocolo mas operando sobre canal criptografado (TLS/SSL), pra evitar captura de dados por intrusos lendo o canal de comunicação.

GET Request

Fazer uma requisição GET em Node.js é bem simples, como mostra o código abaixo. Fazemos GET requests quando queremos ler uma página da Internet ou obter dados de uma API:

Nele, eu carreguei o módulo https ao invés do http que vínhamos trabalhando até então, defini que o site que vamos acessar é o google.com.br, na página ‘about’, usando o método GET (pois queremos obter as informações desta página) e na porta 443.

A porta 443 é a padrão para HTTPS, enquanto que a 80 é a padrão para HTTP.

Todas estas definições foram armazenadas em uma constante options que será passada para a função https.request que criará um novo objeto de requisição (o ‘req’). O callback desta função será disparado quando o GET terminar. Nesta situação, ele vai imprimir no console os dados retornados.

Além disso, foi determinado um listener (‘on’) para erros, que serão jogados também no console.

Finalizamos e enviamos a requisição através da chamada da função end(). O resultado será um monte de HTML no seu console, nada muito útil, mas funcional.

POST Request

Fazer um POST é igualmente simples, com a diferença de que aqui usaremos o corpo da requisição HTTP, que no GET não é utilizado. Fazemos POST requests quando queremos enviar dados para um servidor (ao invés de receber, como no caso do GET) e o trecho de código abaixo exemplifica isso:

Neste exemplo eu usei os serviços da RequestBin, um site onde você cria uma URL sua para fazer testes de requisições. O resultado da requisição você pode ver abaixo:

Resultado do POST no RequestBin
Resultado do POST no RequestBin

A grande diferença do código do POST vs GET é o objeto data, onde criamos um JSON (uma notação bem popular para envio de dados pela Internet) e enviamos ele usando a função req.write, lá no final do código.

Note que ao criarmos o https.request também definimos um callback para exibir os dados retornados pelo POST. Sim, não é somente o GET que retorna dados, o POST também retorna o conteúdo da resposta, embora seu uso primário seja para enviar dados.

PUT, DELETE, PATCH, etc

Existem muitos outros verbos HTTP, cada um com a sua utilidade. Embora possamos emular qualquer comportamento usando apenas GET e POST, é interessante usar e implementar os verbos adequados para garantir o correto funcionamento dos servidores web.

Outros verbos úteis são:

  • PUT: para atualizar um documento;
  • DELETE: para excluir um documento;
  • PATCH: para atualizar parte de um documento;

A forma de uso é a mesma que foi exemplificada no POST, mudando apenas no objeto options o method utilizado.

E com isso encerramos este nosso extenso artigo/tutorial sobre o protocolo HTTP e sua aplicação no Node através do módulo homônimo. Querendo aprender como utilizar HTTP na prática através de construção de WebAPIs, acesse este post com Mongo, este com MySQL e este com SQL Server.

Ficou com alguma dúvida? Deixe nos comentários terei muito prazer em ajudar!

Curtiu este tutorial? Conheça o meu curso online de Node.js e MongoDB para aprender a fazer aplicações web e APIs incríveis com esta fantástica plataforma. Basta clicar no banner abaixo!

Curso Node.js e MongoDB