Desenvolvendo Aplicações RESTFul utilizando Node.js

Prévia do material em texto

Capítulo 
15 
 
Desenvolvendo Aplicações RESTFul utilizando       
Node.js 
Aislan Rafael Rodrigues de Sousa e Washington Henrique Carvalho                 
Almeida 
Abstract 
The development of web applications and services has grown due in part to the                           
popularization of new and more productive technologies and the popularization of                     
them. This chapter presents basic web fundamentals through the HTTP communication                     
protocol, which is a widely used and widespread technology. REST architectural style                       
that makes use of such technologies to their full potential. Also presented is the Node.js                             
tool that has a low learning curve and allows developing solutions to provide services                           
with high scalability along with the application example that uses the REST                       
architectural style. 
Resumo 
O desenvolvimento de aplicações e serviços web tem crescido devido, em parte, a                         
popularização de novas tecnologias mais produtivas e a popularização das mesmas. No                       
presente capítulo é apresentado fundamentos básicos da web através do protocolo de                       
comunicação HTTP, que é uma tecnologia bastante utilizada e difundida. O estilo                       
arquitetural REST que faz uso de tais tecnologias em todo seu potencial. Também será                           
apresentado a ferramenta Node.js que possui uma baixa curva de aprendizado e                       
permite desenvolver soluções para prover serviços com alta escalabilidade junto com o                       
exemplo de aplicação que utiliza o estilo arquitetural REST. 
15.1. Introdução 
Com a massificação tecnológica das últimas décadas em 2016, 51% dos lares brasileiros                         
têm acesso à internet [CGI.BR 2016]⁠. A população brasileira possui cada vez mais                         
acesso a internet e utiliza diversos diversos dispositivos para fazer o acesso a mesma,                           
dos quais podemos citar ​smartphones ​, ​tablets ​, ​notebooks entre outros. Cresce também a                       
demanda por aplicações dos mais diversos tipos incluindo ​web services para que outras                         
 
III Escola Regional de Informática do Piauí. Livro Anais - Artigos e Minicursos, v. 1, n. 1, p. 532-548, jun, 2017.
www.eripi.com.br/2017 - ISBN: 978-85-7669-395-6
 
 
aplicações possam consumir esses dados. 
O sucesso da WEB acontece, em grande parte, por conta de que sua arquitetura                           
de ​software foi projetada para atender as necessidades de hipermídia distribuída em                       
larga escala [Fielding, 2000]. O HTTP (​Hypertext Transfer Protocol​) é o principal                       
protocolo de comunicação para as aplicações web. Outro fator que contribuiu para o                         
crescimento da web foi a popularização do REST (​Representational State Transfer ​) que                       
consiste em um conjunto de princípios de arquitetura que, quando seguidas, permite a                         
criação de um projeto com interface bem definidas.  
Aplicações que que utilizam os princípios REST são chamadas de RESTFul. O                       
REST é frequentemente aplicado para disponibilizar serviços para outros aplicações                   
( ​web services​) e o mesmo utiliza integralmente as mensagens HTTP para se comunicar                         
através do que já é definido no protocolo. 
Segundo a Stack OverFlow (2017) a linguagem de programação JavaScript é                     
uma das mais populares entre os desenvolvedores. Inicialmente seu uso era voltado                       
apenas para o uso em navegadores. O surgimento de novas ferramentas como o Node.js                           1
e NPM contribuiu para que a linguagem fosse amplamente utilizada para finalidades                       2
além do que ela foi inicialmente idealizada.  
Desde 2010 até os dias de hoje, o Node.js cada vez mais provou ser uma                             
plataforma excelente na solução de diversos problemas, principalmente para construção                   
de APIs RESTful. Sua arquitetura ​Single Thread que realiza operações de entrada e                         
saída não bloqueantes rodando em cima da linguagem de programação JavaScript. 
15.2 Referencial Teórico  
Para o entendimento do estudo de caso exposto neste é necessária a apresentação de                           
alguns conceitos. Será apresentado o protocolo HTTP, o estilo arquitetural REST, a                       
linguagem de programação JavaScript e também a ferramenta Node.js. 
15.2.1 Protocolo HTTP 
Ao acessar a internet um determinado usuário utiliza um navegador como por exemplo                         
o google chrome ou firefox . O usuário informa um endereço e o navegador faz uma                             3 4
requisição o qual é respondido por um servidor. Essa forma de trabalhar onde um                           
cliente faz uma requisição e o servidor responde é chamada de arquitetura cliente                         
servidor. Para que essa comunicação ocorra deve haver regras de comunicação, ou seja,                         
um protocolo que estabelece a forma com que o cliente e servidor devem se comunicar.  
O principal protocolo de internet é o HTTP o qual será nosso objeto de estudo.                             
A figura 15.1 apresenta a representação gráfica de como ocorre esse processo.   
 
1 Disponível em https://nodejs.org 
2 Disponível em https://www.npmjs.com/ 
3 Disponível em https://www.google.com/chrome 
4 Disponível em https://www.mozilla.org/pt-BR/firefox/new/ 
 
 
 
 
Figura 15.1 - Representação do HTTP 
 
O protocolo HTTP tem como objetivo distribuir objetos de hipermídia os quais                       
são referenciados por uma URL(​Uniform Resource Locator ​) [EMER 2014]. Por URL                     
podemos entender por regras bem definidas para descrever recursos disponíveis na                     
WEB, ou seja, são os endereços utilizados na WEB um cliente para fazer acesso ao                             
servidor deve informar uma URL.  
Para organizar a comunicação entre servidor e cliente o HTTP são estabelecidos                       
cabeçalhos para a requisição do cliente e a resposta do servidor. No cabeçalho da                           
requisição podemos encontrar informações como por exemplo preferência de idiomas,                   
codificação e formato de conteúdo na resposta [EMER 2014].  
Um usuário ao utilizar um navegador informando um determinado endereço,                   
como por exemplo http://www.eripi.com.br/2017, é automaticamente feita uma               
requisição utilizando o método GET do protocolo HTTP. Um método do protocolo                       
HTTP serve para reportar qual é a intenção ou ação desejada a ser executada.  
Ainda sobre os métodos HTTP pode-se destacar dois conceitos importantes: (i)                     
idempotentes e (ii) seguro. Temos um método idempotente quando o mesmo é chamado                         
n vezes e traz sempre o mesmo resultado. Já o método seguro se trata quando o mesmo                                 
não altera um recurso disponível no servidor.   
A figura 15.2 demonstra a saída no terminal de uma requisição feita utilizando o                           
curl em um terminal. O curl que é uma ferramenta em modo texto utilizada para                             
transferir dados pela sintaxe de chamada [CURL 2017]. O comando utilizado no                       
terminal foi: ​curl http://www.eripi.com.br/2017 -v ​. Ainda observando a figura 15.2 o                     
texto precedido de > representa as informações da requisiçãofeito pelo cliente e o                           
precedido de < representa a resposta dada pelo servidor. Podemos observar que na                         
requisição é passada informações como o método, a versão do protocolo utilizado e o                           
endereço do servidor. 
 
 
 
 
 
Figura 15.2 - Exemplo de cabeçalho HTTP 
 
Temos os métodos propostos por Fielding (1999) para a especificação do HTTP                       
1.1:  
● GET ​- Tem o objetivo obter um recurso que representado por uma identificação                         
única denominado URI (​Uniform Resource Identifier ​). 
● HEAD - O método HEAD é idêntico ao GET exceto que o mesmo não retorna o                               
corpo da mensagem apenas o cabeçalho. 
● POST ​ - Serve para criar novos recursos no servidor.  
● PUT  ​- Altera um recurso no servidor.   
● DELETE ​- Tem objetivo de excluir um recurso do servidor. 
Os métodos HEAD e GET são métodos seguros pois os mesmos apenas                       
retornam informações sem alterar recurso. Os métodos PUT e DELETE são                     
idempotentes pois apesar de poder alterar algum recurso no servidor os mesmos sempre                         
trazem o mesmo resultado.  
O método POST não se encaixa em nenhum dos dois conceitos pois ele                         
usualmente é utilizado para criar novos recursos e trazendo resultados diferentes. Ao se                         
fazer uma requisição junto a resposta do servidor é retornado um código de status que                             
informa ao cliente o resultado da requisição.  
O código de status é denominado ​status code e é composto por um número                           
inteiro por três dígitos e informa ao cliente o resultado da requisição [FIELDING 1999].                           
No exemplo da figura 15.2 o status retornado é o 301 movido permanentemente, ou                           
seja, significa que o recurso que deveria corresponder ao endereço inicial foi                       
redirecionado permanentemente para outro endereço. Os números de status code são                     
divididos em 5 (cinco) famílias: (i) 1XX - representam informações; (ii) 2XX -                         
representa que a operação foi realizada com sucesso; (iii) 3XX - redirecionamentos; (iv)                         
4XX - erro originado no cliente e (v) 5XX - erros originados no servidor.   
 
 
 
15.2.2 REST 
REST é um estilo arquitetural para sistemas de hipermídia distribuídos [FIELDING                     
2000]. Podemos também dizer que REST é uma abordagem para desenvolvimento                     
serviços web que busca simplicidade e baixo acoplamento [SALVADORI 2015]. Como                     
citado anteriormente o termo RESTFul é utilizado para designar aplicações que                     
implementam os princípios definidos no estilo arquitetural REST. Pode ser utilizado                     
qualquer protocolo para implementar o estilo arquitetural REST, mas no presente                     
trabalho o protocolo HTTP será adotado como padrão devido a sua popularidade na                         
Web.  
Para entender melhor o estilo arquitetural é importante destacar três conceitos                     
importantes: (i) recurso; (ii) operações e (iii) representações. Recurso é qualquer                     
informação a qual é disponibilizada para os clientes através de um identificador único                         
(URI). Também podemos conceituar recurso como sendo a fonte de representações e as                         
representações são um conjunto de dados que representam o estado do recurso                       
solicitado [MORO et. al 2011]. As URIs devem possuir um padrão de notação, serem                           
descritivos e possuir uma hierarquia previamente definida [RODRIGUES 2014]. Um                   
mesmo recurso pode ser identificado por um ou mais URIs, mas uma URI identifica                           
apenas um recurso.  
Cada recurso pode ter mais de uma representação, sendo que, cada recurso deve                         
ter pelo menos uma representação. O HTTP possui operações e o recomendado é                         
respeitar a semântica e utilizar adequadamente as mesmas sendo as principais GET,                       
POST, PUT e DELETE. Acontecem casos onde a equipe de desenvolvimento                     
negligência o uso das operações e acaba utilizando o operador GET para realizar as                           
mais diversas ações o que acaba não sendo uma boa prática. A representação de um                             
determinado recurso pode ser feito de diversas formas como por exemplo HTML, PDF,                         
JSON ou XML. A figura 15.3 faz uma representação gráfica envolvendo os conceitos                         
apresentados.   
 
   
Figura 15.3 - Componentes da arquitetura REST 
 
É importante observar que quando é realizada uma requisição a resposta deve                       
conter um status ou mensagem. Como estamos tomando por base o protocolo HTTP                         
deve ser retornado o ​status code ​adequado. A figura 15.4 ilustra uma requisição que um                             
determinado dispositivo ​mobile ​que faz utilizando a operação GET a qual solicita o                         
recurso presente no endereço http://www.eripi.com.br/2017/. Logo após a requisição                 
 
 
 
acontece a resposta do servidor que contém o ​status code 200 o qual indica que tudo                               
aconteceu como o esperado. Ainda na resposta é informado que a representação do                         
recurso retornada é um HTML. Os ​status code pertencente ao protocolo HTTP, os                         
mesmos fornecem uma maneira adequada de categorizar e padronizar as respostas das                       
requisições e ao utilizar o estilo arquitetural REST devem ser obrigatoriamente                     
utilizados [SALVADORI 2014]. 
   
 
Figura 15.4 - Modelo de requisição resposta  
 
Ao desenvolver uma aplicação o foco central são os recursos. Depois de definir                         
os recursos basta utilizar as operações que também são chamados de verbos para                         
manipular esses recursos. Uma boa prática é fazer uso do HATEOAS (​Hypermedia as                         
the Engine of Application State ​) que implica que as representações de recursos devem                         
conter, além dos dados, controles hipermídia com transições válidas.  
Na prática isso ocorre ao adicionar a resposta do servidor endereçamentos para                       
novas requisições a partir da resposta que acabou de ser entregue indicando ao cliente o                             
que pode ser feito a partir daquele determinado recurso.   
Fielding (2000) define restrições para o estilo arquitetural REST o qual serve                       
como princípios do mesmo. Estão listadas abaixo:  
● Arquitectura cliente servidor - visa a separação de responsabilidades como por                     
exemplo a interface do usuário com problemas de armazenamento. Essa                   
abordagem permite ter interfaces diferentes de usuário garantindo a                 
portabilidade em diferente plataformas; 
● Stateless - As requisições devem ser independentes, ou seja, as requisições                     
devem conter todas as informações necessárias para o servidor responder. Na                     
prática o protocolo de comunicação não mantém o estado das requisições não                       
havendo portanto como recuperar informações das requisições anteriores, ou                 
seja, o servidor não deve recorrer a informações armazenadas em sessão de                       
usuário; 
● Cache - Torna possível o cliente armazenar localmenteresultados de                   
requisições. Possibilita a reutilização das informações e aumento da                 
 
 
 
performance. 
● Interface Uniforme - É a restrição central da arquitetura REST. Se configura                       
através do estabelecimento de uma interface uniforme entre cliente e servidor.                     
Define quatro princípios fundamentais: (i) identificação de recursos, (ii)                 
manipulação de recursos por meio de representações, (iii) mensagens auto                   
descritivas e (iv) recursos hipermídia.   
● Sistema em camadas - Permite que a arquitetura seja composta por camadas                       
hierárquicas condicionando os componentes de tal forma com que os mesmos a                       
não terem acesso a outras camadas que não seja a adjacente.  
● Código sob demanda - Permite mover um código no servidor para ser                       
executado no cliente.  
15.2.3 JavaScript 
O JavaScript surgiu em 1995 para rodar no navegador Netscape e posteriormente foi                         
adaptado para a maioria dos navegadores Web [HAVERBEKE 2014]. Idealizado                   
inicialmente para rodar nos navegadores atualizando o conteúdo dinamicamente. Esse                   
contexto contribuiu para que evoluísse de uma forma diferente das outras linguagens                       
focado em performance, criação de interfaces e dar uma melhor experiência para o                         
usuário [NETO 2017]. 
Conforme aconteceu a evolução dos navegadores o JavaScript acompanhou essa                   
evolução. Com o surgimento do conceito de nuvem as aplicações necessariamente                     
precisam ser escaláveis e com esse novo contexto foi necessário tirar maior proveito das                           
máquinas e utilizar o mínimo de recurso possível. Houveram também outras propostas                       
como divisão de carga e micro-serviços.  
É necessário conhecer a especificação da linguagem de script que o JavaScript                       
implementa o ECMAscript. A especificação é mantida pelo ECMA Technical                   
Committee 39 (TC39) o qual é formado por especialistas de grandes empresas [Pinho                         
2017]. Através da especificação é possível acompanhar quais funcionalidades estão                   
disponíveis nas aplicações que implementam a especificação.   
15.2.3 Node.js 
O Node.js pode ser definido como um ambiente ​runtime para a linguagem de                         
programação JavaScript que roda em cima de uma ​engine conhecida como Google V8                         5
[NETO 2017]. O V8 é uma engine criado pela empresa Google para ser utilizada no                             
navegador Chrome.  
O JavaScript é uma linguagem interpretada, mas o V8 interpreta e compila para                         
linguagem de máquina otimizando, com a utilização de heurísticas. A arquitetura do                       
Node.js é não-bloqueante o que faz ela apresentar uma boa performance com o                         
consumo de memória utilizando de forma eficiente o poder de processamento dos                       
servidores [PEREIRA 2013]. 
Pereira (2017) destaca algumas características do Node.js: 
● Single Thread - Cada instância terá instância de apenas um processo. É utilizado                         
5 Disponível em http://code.google.com/p/v8 
 
 
 
programação assíncrona e recursos compartilhados para tirar maior proveito da                   
thread ​ utilizada;  
● Operações de entrada e saída assíncrono e não bloqueante - Facilita execução                       
paralela e o aproveitamento de recursos. 
● Event-loop​ - É orientado a eventos. 
15.3 Estudo de Caso 
As ​Web Services REST também conhecidas como WEB API são bastante utilizadas na                         
implementação de sistemas distribuídos [SALVADORI 2015]. Quando uma               
determinada aplicação implementa os princípios REST, como já foi dito, é denominada                       
RESTFul. O estudo de caso proposto se trata de uma WEB API para prover recursos                             
voltados para controle financeiro pessoal. O foco da aplicação será o gerenciamento das                         
despesas pessoais e será uma plataforma que pode ser utilizada por outros aplicativos                         
fazer gerenciamento dos gastos pessoais. 
A aplicação permite: (i) cadastrar uma nova despesa; (ii) confirmar o pagamento                       
da despesa; (iii) cancelar uma determinada despesa caso a mesma não seja mais                         
necessária; (iv) retornar todas as despesas cadastradas e (v) retornar uma despesa em                         
específico. Para a representação dos recursos foi escolhido o JSON (​JavaScript Objetct                       
Notation ​). Podemos observar na figura 15.5 a representação de uma despesa utilizando                       
JSON. 
 
 
Figura 1.5 - Representação de uma despesa utilizando JSON 
 
A despesa possui uma descrição que indica a natureza da despesa, mês                       
indicando o mẽs em que a despesa foi realizada, o ano indicando o ano que a despesa                                 
foi realizada, o valor a ser pago por conta da despesa e o status que possui três possíveis                                   
valores CRIADO, CONFIRMADO ou CANCELADO. O status CRIADO serve para                   
indicar que a despesa foi criada, o CONFIRMADO serve para indicar que a despesa foi                             
paga e o CANCELADO indica que por algum motivo a despesa deve ser                         
desconsiderada.   
15.3.1 Estrutura do Projeto 
A linguagem de programação escolhida é o JavaScript e a ferramenta o Node.js.                         
Também é utilizado o NPM (​Node Pakage Manager​) o qual é utilizado para criar                           
projetos, automatizar tarefas e gerenciar dependências [NETO 2017]. Foram utilizados                   
 
 
 
as seguinte bibliotecas que estão presentes no repositório do NPM: (i) express; (ii)                         
express-load; (iii) express-validator; (iv) body-parser e o (v) mysql.  
O express estende as capacidades do Node.js adicionando ​middlewares ​e outras                     
capacidades [ALMEIDA 2014]. O express-load tem a função de auxiliar no processo de                         
carregar os módulos para que os mesmos sejam feitos automaticamente. O                     
express-validator tem a função de auxiliar na validação de dados de entrada.  
Já o body-parser serve para transportar os dados como JSON pois as requisições                         
com as operações POST ou PUT ao serem executadas transporta os dados como texto.                           
Por último a biblioteca mysql serve para facilitar a comunicação com o sistema                         
gerenciador de banco de dados MySQL o qual será utilizado para fazer a persistência                           6
dos dados.  
A figura 15.5 representa a estrutura de pastas utilizada na WEB API. O nome do                             
projeto é ​node-simple-rest-wallet​. Dentro do projeto temos as pastas ​config ​, ​controllers ​,                     
persistencia e ​routes ​. A pasta ​config é destinada para arquivos de configuração. Foi                         
utilizado o arquivo custon-express.js para armazenar todas as configurações utilizadas                   
no express.  
Temos na pasta routes todas as rotas uma para o recurso e operação. Na pasta                             
controlles temos a implementação das rotas, ou seja, o código onde de fato é                           
implementação a lógica por trás de cada operação. Na pasta principal temos os dois                           
arquivos package.json e app.js. O package.json tem o papelde guardar as configurações                         
do NPM referente ao projeto, guardar os ​scripts para executar a aplicação e os testes                             
[NETO 2017]. O arquivo app.js é o ponto de partida onde será informado o endereço                             
do servidor e a porta o qual irá funcionar.   
 
 
Figura 15.5 Estrutura de pastas e arquivos 
 
É necessário conhecer os detalhes dos recursos e como realizar requisições para                       
que outras aplicações possam interagir com a WEB API proposta [SALVADORI 2014].                       
É apresentado na tabela 15.1 os recursos disponíveis e as operações permitidas para                         
6 Disponível em https://www.mysql.com/ 
 
 
 
cada um. O recurso ​/despesas/despesa possibilita executar duas operações sendo elas                     
POST e o GET. Temos também o recurso ​/despesas/despesa/{id} que permite utilizar a                         
variável id e possibilita as operações GET, PUT e DELETE. A variável id identifica                           
unicamente uma determinada despesa o qual deve ser substituído pelo valor desejado.   
 
Tabela 15.1 Recursos e Operações 
Recurso  Método  Descrição 
/despesas/despesa  POST  Cadastrar nova despesa 
GET  Obter a lista contendo todas as despesas 
/despesas/despesa/{id}  GET  Obter despesa identificada pelo id 
PUT  Confirmar pagamento de despesa 
DELETE  Cancelar despesa  
 
Na WEB API esse mapeamento é feito dentro da pasta ​routes​. A aplicação                         
representa um serviço web, ou seja, funcionalidades definidas através de rotas. A rota                         
pode ser entendida como um serviço a ser implementado e para isso necessita de um                             
endereço a partir do qual esse serviço será acessado, uma função de retorno que deverá                             
conter o código a ser executado e a operação (método HTTP) que define a forma de                               
acesso a rota.  
Na figura 15.6 temos o código fonte do mapeamento das rotas. Pode-se observar                         
que é declarado antes das rotas uma constante que recebe um objeto despesa. O objeto                             
está na pasta ​controllers onde o mesmo contém funções que implementam as ações para                           
cada rota. Essa separação permite visualizar no código fonte, de forma simplificada,                       
cada recurso com suas respectivas operações.  
 
 
Figura 15.6 - Representação do mapeamento de rotas 
  
A persistência ficará a cargo do sistema gerenciador de banco de dados MySQL.                         
Na figura 15.7 temos a representação do esquema da tabela despesa. Na pasta                         
persistência foi implementado o objeto DespesaDAO o qual possui funções que                     
 
 
 
realizam a persistência e recuperação de dados no banco criado através do MySQL. 
  
 
Figura 15.7 - Esquema da tabela despesas 
  
15.3.1 Implementação das rotas 
A primeira rota tem como endereço /despesas/despesa e a operação POST. Na                       
requisição é passado um JSON com os dados da despesa. A WEB API ao receber a                               
requisição validar, persistir no banco e retornar os dados. Na resposta, entre outras                         
informações, é passado o ​status code 201 que indica que o recurso foi criado com                             
sucesso, o tipo da representação (​application/json​) e o JSON contendo as informações                       
que foram persistidas.  
Ao ser criada a despesa o seu status passa a ser “CRIADO” indicando que a                             
despesa foi criada, mas ainda não foi paga. Ainda no JSON, seguindo o princípio                           
HATEOAS, é acrescentado informações (​links ​) de quais os possíveis próximos passos                     
que podem ser tomados a partir do recurso que criado. A figura 15.8 faz a representação                               
de uma requisição a rota.  
 
 
Figura 15.8 - Representação da rota POST /despesas/despesa 
 
 
 
 
A implementação da rota POST /despesas/despesa está na função postDespesa                   
que faz parte do objeto despesa dentro da pasta ​controller ​. A figura 15.9 demonstra o                             
código fonte onde podemos observar que é recebido os dados da requisição e logo                           
depois é alterado o  ​status ​ da despesa para CRIADO.  
Para controlar a conexão com o banco de dados é utilizado o objeto                         
connectionFactory e o mesmo é passado como parâmetro para o objeto DespesaDAO.                       
Ambos estão implementados na pasta persistência.  
Caso aconteça algum erro durante a persistência é retornado um ​status code 500                         
indicando que houve um erro interno ao servidor. Se não houver nenhum problema é                           
indicado uma ​location ​para informar o endereço do novo recurso criado e retorna um                           
JSON com as informações da despesa e os ​links ​com possíveis rotas que podem ser                             
requisitadas a partir do recurso que acabou de ser criado. 
 
 
Figura 15.9 Código fonte da implementação da rota POST /despesas/despesa 
 
Na rota GET /pessoas/pessoa é retornado um ​status code 200 que indica que                         
 
 
 
tudo ocorreu como o esperado e um ​array de JSON com todas as despesas. A operação                               
GET é segura pois a mesma não altera os recursos no servidor. A figura 15.10 faz a                                 
representação gráfica da rota GET /pessoas/pessoa.  
 
 
Figura 15.10 - Representação da rota GET /despesas/despesa 
A implementação da rota GET /despesas/despesas está na função getDespesas e                     
consiste apenas em consultar no banco de dados as despesas existentes e retornar às                           
mesmas em um ​array ​. Assim como na rota anterior caso exista algum problema na                           
conexão é retornado um ​status code 500 indicando ao cliente que houve um erro interno                             
no processamento no servidor. A figura 15.11 demonstra a implementação da rota. 
 
 
Figura 15.11 - Código fonte Código fonte da rota GET /despesas/despesa 
 
A rota GET /despesas/despesa/{id} é análoga a despesa a rota GET                     
/despesas/despesa. A diferença está no retorno o qual consiste em um JSON com apenas                           
a despesa identificada através do parâmetro id. A figura 15.12 mostra a representação                         
gráfica da rota. A figura 15.12 faz a representação gráfica da rota.  
 
 
 
 
 
Figura 15.12 Representação da rota GET /despesas/despesa/{id} 
 
Em sua implementação pode ser observado que o parâmetro id é utilizado para                         
recuperar do banco de dados a despesa qual o mesmo identifica unicamente. Na                         
resposta é retornado o ​status code padrão, ou seja, o 200. A figura 15.13 apresenta o                               
código fonte da rota GET /despesas/despesa/{id}. 
 
Figura 15.13 Código fonte da rota GET /despesas/despesa/{id} 
 
Através da rota PUT /despesas/despesa/{id} é possível confirmar o pagamento                   
da despesa identificada através do parâmetro id. A operação PUT é idempotente pois a                           
mesma sempre traz o mesmo resultado independente da quantidade de vezes que é                         
executada. Caso tudo ocorra como esperado também irá retornar o ​status code 200. A                           
figura 15.14 demonstra a representação gráfica da rota PUT /despesas/despesa/{id}.Figura 15.14 Representação da rota PUT /despesas/despesa/{id} 
 
A função que implementa a rota PUT /despesas/despesa/{id} é o putDespesa.                     
Após pesquisa a despesa a qual o parâmetro id identifica é feito uma atualização                           
indicando o ​status mudou para CONFIRMADO. Na figura 15.15 é possível verificar a                         
implementação da rota. 
 
Figura 15.15 Código fonte da rota PUT /despesas/despesa/{id} 
 
Por fim, temos a rota DELETE /despesas/despesa/{id} onde a mesma tem o                       
objetivo de cancelar uma determinada despesa mudando o seu status para                     
CANCELADO através do id passado como parâmetro. Caso ocorra tudo com sucesso é                         
retornado o status code 204. A figura 15.16 trás a representação gráfica da rota.  
 
 
 
 
 
 
Figura 15.16 Representação da rota DELETE /despesas/despesa/{id} 
 
A função que implementa a rota DELETE /despesas/despesa/{id} é a                   
deleteDespesa. A operação DELELTE também é idempotente. Caso ocorra tudo como                     
esperado a resposta do servidor retorna o ​status code ​ 204. 
 
 
Figura 15.17 Código fonte da rota DELETE /despesas/despesa/{id} 
 
15.4 Considerações Finais 
Neste capítulo foram apresentados conceitos gerais sobre a arquitetura de aplicações                     
web sobre o protocolo HTTP baseada em serviços REST implementados com a                       
tecnologia Node.js. A popularização da Internet no Brasil ampliou a gama de serviços                         
oferecidos para a população, abrindo um novo leque de possibilidades para a expansão                         
das implementações baseadas em arquiteturas melhores adaptadas a essa nova realidade. 
Neste trabalho foram apresentados os conceitos básicos para implementação de                   
web services e um roteiro de implementação detalhado com objetivo de demonstrar as                         
melhores práticas para desenvolvimento de soluções REST com Node.js apoiadas nas                     
técnicas de engenharia de software, buscando alta coesão, baixo acoplamento, melhor                     
manutenibilidade, escalabilidade e agilidade no desenvolvimento. 
 
 
 
Referências  
ALMEIDA, F. MEAN Full Stack JavaScript para aplicações web com                   
MongoDB, Express, Angular e Node. Casa do Código, 2014.  
CGI.BR. TIC Domicílios 2015. São Paulo: cgi.br, 2016. 
CURL. Disponível em <https://curl.haxx.se/>. Acesso em 05 de Maio de 2017. 
EMER, Jean Carlo. O grande desencontro do HTTP com o HTML: 6 de janeiro de                             
2014. Disponível em:     
<http://tableless.com.br/o-grande-desencontro-http-com-o-html/>. Acesso em 10 de         
Maio 2017. 
FIELDING, Roy et al. Hypertext transfer protocol--HTTP/1.1. 1999. 
FIELDING, R. T. REST: Architectural Styles and the Design of Network-based                     
Software Architectures. Tese (Doctoral dissertation)—University of California,             
Irvine, 2000. Disponível em:       
<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>  
HAVERBEKE, Marijn. Eloquent javascript: A modern introduction to programming.                 
No Starch Press, 2014. 
MORO, T. D.; DORNELES, C. F.; REBONATTO, M. T. Web services WS- * versus 
Web Services REST. REIC - Revista de Iniciação Científica, v. 11, n. 1, p. 36–51, 
2011. 
NETO, W. Construindo APIs testáveis com Node.js. [s.l.] LeanPub, 2017. 
PEREIRA, C. R. Construindo APIs Rest com Node.js. 1. ed. São Paulo: Casa do                           
Código, 2016.  
PEREIRA, C. R. Node.js: Aplicações web real-time com Node.js. São Paulo: Casa do                         
Código, 2013.  
PINHO, D. M. DE. ECMAScript 6 - Entre de Cabeça no futuro do JavaScript. Casa do                               
código, 2017. 
RODRIGUES, L. Desenvolvimento de Aplicações Móveis com Serviços RESTful e                   
HTML5. p. 171–179, 2014. 
SALVADORI, I. L. Desenvolvimento de Web APIs RESTful semânticas baseadas em                     
JSON. Igarss 2014, n. 1, p. 1–5, 2015. 
STACK OVERFLOW. Developer Survey Results 2017. Disponível em               
<https://insights.stackoverflow.com/survey/2017>. Acesso em 01 de Maio de 2017.