Node.js Desenvolvendo Aplicações RESTFul utilizando

apresentado a ferramenta Node.js ... ( H yp ert e xt Tr ansfe r Pro ... O surgimento de novas ferramentas como o Node.js1 e NPM2 contribuiu para que...

9 downloads 237 Views 1MB Size
 

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

 

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   

    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.js1  e  NPM2  contribuiu  para  que  a  linguagem  fosse  amplamente  utilizada  para  finalidades  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  chrome3  ou  firefox4.  O  usuário  informa  um  endereço  e  o  navegador  faz  uma  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   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/  2

 

   

  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ção  feito  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  localmente  resultados  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 V85  [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  MySQL6  o  qual  será  utilizado  para  fazer a persistência  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 papel de 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 

GET 

Obter despesa identificada pelo id 

PUT 

Confirmar pagamento de despesa 

DELETE 

Cancelar despesa  

/despesas/despesa/{id} 

  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 . 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:  .  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:    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  . Acesso em 01 de Maio de 2017.