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.
