DESENVOLVIMENTO

PARA DISPOSITIVOS
MÓVEIS

Victor Luiz Simas

Consumo de serviços
Web RESTful
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Analisar o uso de REST e as suas aplicações.

„„ Identificar REST em aplicações móveis como endpoints de aplicativos
backend.
„„ Exemplificar o consumo de serviço Web RESTful em uma aplicação.

Introdução
O acesso à internet por dispositivos móveis cresce ano após ano, até o
ponto em que se tornou o principal meio de conexão à rede mundial de
computadores, utilizados no dia a dia para diferentes fins. Todavia, para que
a aplicação funcione adequadamente de acordo com as expectativas do
usuário e atenda às diversas funcionalidades, deve-se integrá-la a outros
sistemas (geralmente remotos). Para essa integração, o mais comum é
usar a application programming interface (API) de representational state
transfer (REST) e o padrão de arquitetura RESTful, bem como a separação
de conceitos entre back-end e front-end.
Neste capítulo, você estudará uma API REST, suas aplicações, seu uso
no desenvolvimento de aplicações Web, como acontece o consumo de
dados por meio dos serviços em endpoints de API e a partir de API REST
utilizando os recursos da plataforma Ionic com TypeScript.

Aplicações mobile e acesso aos dados remotos

Com a evolução dos aparelhos celulares, desde os simples telefones aos meios
completos de comunicação, em que realizar chamadas é apenas uma das
funcionalidades), a demanda por aplicativos para variados usos (como redes
sociais, mensagens, aplicações bancárias e e-commerce) também aumentou
2 Consumo de serviços Web RESTful

na última década. Pode-se afirmar, por exemplo, que o smartphone é hoje o

principal meio de acesso à internet no Brasil, conforme a pesquisa divulgada
pelo Instituto Brasileiro de Geografia e Estatística (IBGE) e outros veículos
de comunicação.
Segundo o IBGE, a internet é acessada em 70,5% dos domicílios brasileiros,
sendo que 69% o fazem por meio de telefones celulares, e apenas 38,8% por
computadores (os números não são absolutos, havendo um entrelaçamento, pois,
como há pessoas que utilizam ambos, elas representam os dois grupos citados)
(INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2018).
Já a Folha de São Paulo traz a informação de que 49% da população bra-
sileira acessa à internet somente por meio de dispositivos móveis (Figura 1), e
4% o fazem apenas pelo computador (sendo 47% para ambos os dispositivos)
(AMPUDIA, 2018).

Figura 1. Uso massivo de dados por meio de smartphones.

Fonte: DisobeyArt/Shutterstock.com.

Portanto, estes números justificam o crescente investimento em aplica-

ções direcionadas aos dispositivos móveis pessoais, bem como uma maior
preocupação com sua qualidade e confiabilidade. Contudo, eles não possuem
o mesmo poder computacional e de armazenamento que os computadores
pessoais, muitas vezes acessando à internet por meio de conexões lentas,
instáveis e limitadas (pacotes de dados).
 Consumo de serviços Web RESTful 3

Na maioria dos casos, as aplicações que estão instaladas e em execução

nos dispositivos precisam acessar dados disponíveis em sistemas remotos, nas
plataformas que dependem do acesso à internet para sua total funcionalidade.
Como consultar o estoque em uma loja virtual e efetuar uma compra?
Como pagar a fatura e verificar o extrato da conta no aplicativo do banco?
Tais aplicativos atuam como a camada de apresentação dos dados, facilitando
a interação com o usuário, porém, não processam esses dados, nem os arma-
zenam efetivamente. Então, como os dados se tornam disponíveis?
Existem diversas formas de executar esta tarefa, mas uma técnica que se
destacou pela sua versatilidade e relativa praticidade foi expor os métodos (ou
funções) para que pudessem ser chamados a partir de outro sistema, por meio
da própria Web. Isso torna possível efetuar, por exemplo, uma solicitação de
determinados dados e obter uma resposta padronizada, que é recebida e com-
preendida pelo sistema que a chamou, dando continuidade ao processamento
e à exibição dos dados em questão.
De um lado, há a aplicação que recebe as requisições de dados por meio de
chamadas Web (transmitindo os dados como as requisições Hypertext Transfer
Protocol [HTTP]) e, de outro, uma aplicação que consome esses dados.
O uso de técnicas baseadas em serviços, chamadas sobretudo de assín-
cronas, permitiu que uma aplicação fosse dividida em camadas ou em partes
distintas, que funcionam conectadas entre si por essas requisições. Assim,
surgiram os conceitos de front-end, mais focado em apresentar os dados aos
usuários e receber sua interação diretamente; e o back-end, que é a parte
invisível do sistema e contém o maior conjunto das regras de negócios e
processamento de dados, bem como a maior carga de trabalho para a máquina
que o executa. Veja um exemplo desses dois conceitos na Figura 2.
Esta separação permite uma maior flexibilidade no desenvolvimento de
aplicações de diversos portes. Ao separar a apresentação do processamento
bruto, utiliza-se, por exemplo, o mesmo serviço de back-end para diversas
aplicações front-end (responsáveis por interagir com o usuário), como as
aplicações de página única (SPA, em inglês single page application), que
reduzem a quantidade de dados trafegados; aplicações desenvolvidas para
dispositivos móveis, muitas vezes com conexões, processamento e memória
bastante limitados (Figura 3); e telas em um sistema desktop. Nos casos citados,
pode-se dizer que o back-end expõe suas funções (métodos) de chamada aos
dados por meio da Web.
4 Consumo de serviços Web RESTful

Controle
de operações

Mensagens

Base de dados

CRM

Frontend Backend

Figura 2. Divisão de conceitos de front-end e back-end, demonstrando de maneira ilustrativa a

possibilidade de utilizar mais de uma interface com o mesmo sistema de fornecimento de dados.

Figura 3. Mensagens, finanças, localização, informação, alimentação e toda uma diversidade

de aplicações disponíveis na ponta dos dedos por meio das aplicações móveis.
Fonte: Jo karen/Shutterstock.com.
 Consumo de serviços Web RESTful 5

As aplicações móveis usam extensivamente o padrão RESTful e o

acesso a API, que é uma metodologia que permite, hoje, existir a imensa
gama de aplicações para variadas necessidades pessoais e profissionais.
Seu uso é relativamente simples, pois ao entender seu conceito e ter um
bom planejamento, não será difícil acessar dados espalhados em servidores
remotos pela Web.
Por exemplo, uma aplicação bancária, mais precisamente um aplicativo
bancário, permite a execução de transações (como pagamentos e transfe-
rências) e a obtenção de informações sobre a conta (como extratos, com-
provantes, etc.).

Quando o usuário solicita o extrato ao banco, por meio do aplicativo móvel, este
encaminha para o servidor (que está na internet ou na nuvem) as informações sobre
o usuário que o acessa, qual sua conta e qual o dado buscado, no caso, o extrato.
Assim, o servidor busca essas informações em seus bancos de dados, prepara uma
estrutura que o aplicativo seja capaz de compreender e retorna tais dados a esse
aplicativo. Este, por sua vez, é responsável por montar a tela e apresentar, de forma
compreensível e objetiva, ao usuário quais foram seus recebimentos e gastos no
período consultado.

Outro exemplo é uma aplicação com foco em redes sociais e comparti-

lhamento de informações. Ao tirar uma foto com seu aparelho (Figura 4),
você pode imediatamente compartilhá-la por meio de poucos toques na tela,
pois basta ter a aplicação da rede que deseja utilizar (Facebook, Instagram,
WhatsApp, entre outras) instalada e configurada, bem como estar efetivamente
cadastrado e logado nela.
6 Consumo de serviços Web RESTful

Figura 4. Foto sendo tirada em um dispositivo móvel para posterior compartilhamento

instantâneo.
Fonte: El Nariz/Shutterstock.com.

O usuário tira uma foto, que é armazenada na memória do dispositivo ou no cartão

adjacente, e, ao clicar no ícone compartilhar, o sistema sugere os aplicativos que
possuem essa facilidade (de compartilhamento de imagens).
Esse usuário seleciona o aplicativo, que geralmente permite a inserção de uma
descrição para a foto recém-compartilhada e, após confirmação, o aplicativo a converte
em caracteres passíveis de serem enviados por meio de API REST (em geral, Base64).
Ao terminar o processamento local, há a chamada de um endereço de uma API, que
contém (de forma criptografada) os dados sobre o usuário que está compartilhando, sua
autenticação, o texto descritivo, a imagem em si e para quem ele deseja compartilhá-la.
O servidor recebe essa chamada, efetua o processamento interno de inserir essa
foto na conta do usuário, entre outras tarefas, valida sua conta e finaliza o processo
retornando se a solicitação foi bem-sucedida ou não (nesse caso, qual erro ocorreu).
 Consumo de serviços Web RESTful 7

Protocolo Hypertext Transfer Protocol e

requisições representational state transfer
O protocolo HTTP é a base da tecnologia da Web e, por meio dele, um cliente
(aplicação) efetua a requisição a um servidor, que responderá de acordo com a
solicitação enviada e a disponibilidade dos dados. Porém, essa tecnologia não
é nova e foi desenvolvida por Tim Berners-Lee, cientista da Organização Eu-
ropeia para Pesquisas Nucleares (CERN), objetivando o compartilhamento de
trabalhos e artigos científicos, em 1989 (FOROUZAN; MOSHARRAF, 2013).
Contudo, ao longo dos anos, foram incorporados diversos aprimoramentos
tecnológicos nele, ao mesmo tempo em que a Web se tornava mais popular
e acessível ao público. Essas incorporações permitiram o uso não apenas do
hipertexto, como também de diversos tipos de mídia.
O HTTP define um formato para mensagens de solicitação e resposta
(FOROUZAN; MOSHARRAF, 2013), bem como o conjunto de regras de
negócios que determinam como o cliente e o servidor tratarão as mensagens
trocadas entre si nas requisições. Basicamente, o protocolo mostra que essas
requisições podem ser segmentadas em métodos, sendo os principais defini-
dos de acordo com a norma da Internet Engineering Task Force/Request for
Comments (IETF/RFC) 2616.

„„ GET: é responsável por buscar quaisquer informações e identificado

por meio do Uniform Resource Identifier (URI) chamado. Assim, uma
requisição utilizando esse método informa ao servidor os dados que
deseja na sequência do seu endereço, por exemplo, ao chamar http://
aplicacao/alunos/lista?turma=1234. Nesse caso, o servidor retorna
a lista de alunos em que a turma for igual a 1234 no corpo de uma
mensagem de retorno.
„„ HEAD: é idêntico ao GET, exceto pelo fato de que o servidor não retorna
um corpo na mensagem de retorno, apenas um cabeçalho HTTP será
retornado. Mais adiante neste capítulo, você verá os códigos de resposta,
que podem trazer informações valiosas com um mínimo de dados.
„„ POST: é usado para requisições em que os dados enviados são contidos
no corpo da mensagem, não em seu endereço, o que torna esse método
mais seguro (em comparação ao GET) para envio de informações
sensíveis, como senhas.
„„ PUT: é similar ao método POST, mas utilizado quando os dados enviados
são armazenados em uma URI já conhecida.
8 Consumo de serviços Web RESTful

„„ DELETE: é a exclusão de determinado registro na aplicação servidora,

em que se passa os dados por meio de uma URI, e o servidor responde
pelos códigos de resposta HTTP (vistos na sequência). Por exemplo,
uma requisição DELETE feita a http://aplicacao/produtos/1020, assim,
o servidor exclui o registro do produto cujo identificador é 1020.

Existem outros métodos implementados sobre HTTP, mas os mencionados

anteriormente são os de maior relevância.
De acordo com a rede de desenvolvedores da Mozilla, em uma requisição
HTTP, deve-se informar um cabeçalho composto de uma linha contendo o
método e a versão do protocolo (usualmente HTTP/1.1); a informação sobre
quem fez a solicitação (navegador ou sistema); os formatos de representação
suportados; a codificação; e o tamanho da mensagem. Alguns métodos também
possuem um corpo, como PUT e POST, que contêm a carga (a informação que
deseja inserir no servidor), o tamanho do conteúdo e seu tipo.

Os métodos PUT e POST podem ser utilizados para inserir ou alterar informações,
porém, existe uma diferença fundamental entre eles. Segundo a norma RFC 2616,
deve-se utilizar PUT quando a URI que identifica o recurso já existe; e POST quando o
sistema criar uma nova URI para os dados inseridos ou alterados (IETF/RFC 2616, 1999).

Já o servidor responderá à solicitação com uma mensagem também padro-

nizada. Essa resposta inicia-se pelo protocolo utilizado (geralmente HTTP/1.1),
por um código de retorno (que informa se a solicitação foi ou não bem-sucedida,
etc.) e uma mensagem resumida sobre esse retorno. Consta ainda informações
sobre o tipo do servidor, algumas configurações e, às vezes, o corpo da men-
sagem com os dados processados. Note que nem toda mensagem de retorno
apresenta um conjunto de dados específicos para retornar, porque, em diversas
situações, apenas o código já é suficiente.
 Consumo de serviços Web RESTful 9

A seguir, veja os códigos de retorno HTTP mais comuns.

As respostas de sucesso são (CÓDIGOS ..., 2019):
„„ 200 OK — solicitação ok;
„„ 201 Created — requisição bem-sucedida e recurso criado com sucesso;
„„ 202 Accepted — requisição recebida, mas nenhuma ação foi tomada;
„„ 204 — solicitação aceita, mas sem precisar enviar dados complementares como
resposta.
As respostas de erro incluem:
„„ 400 Bad Request — requisição inválida, o servidor não conseguiu compreendê-la;
„„ 401 Unauthorized — não autorizado, usuário não autenticado;
„„ 403 Forbidden — proibido, usuário autenticado, mas não tem permissão para acessar;
„„ 404 Not Found — servidor não encontrou o recurso solicitado (talvez o endpoint
não exista);
„„ 405 Method not allowed — erro no método, pode existir a API, mas eventualmente
ela está configurada para receber um GET e foi enviado um POST;
„„ 408 Timeout — tempo esgotado;
„„ 415 Unsupported Media Type — tipo de mídia não suportado pelo servidor;
„„ 500 Internal Server Error — erro no servidor, que encontrou uma situação com a qual
não sabe lidar. Pode ocorrer quando, por exemplo, o servidor Web não encontra
o de aplicação ou esta não está em execução;
„„ 502 Bad Gateway — o servidor obteve uma resposta inválida de outra parte da
aplicação (do back-end);
„„ 503 Service Unavailable — ocorre quando o servidor está em manutenção ou
sobrecarregado, por exemplo.

Para saber mais sobre a estrutura de mensagens HTTP, suas partes e subpartes, acesse
o link a seguir.

https://qrgo.page.link/mx7Ba
10 Consumo de serviços Web RESTful

Padrão representational state transfer

O padrão de comunicação REST se baseia no protocolo de comunicação
HTTP. Já o ponto no servidor que recebe tal requisição, trata e responde
com a informação desejada ou o resultado da ação se chama endpoint, que é
a parte exposta de um método/função que, recebendo os parâmetros neces-
sários, consegue processar o comando e retornar a informação à aplicação
que a originou. Um endpoint ainda é facilmente identificável por se parecer
com um endereço de uma página Web, mesclado com alguns dados enviados
juntamente ao Uniform Resource Locator (URL).
Essa troca de mensagens com transferência de representação de estado na
requisição compreende o REST (FIELDING, 2000). De acordo com Fielding,
uma requisição REST deve conter toda informação necessária para que o
servidor entenda a requisição, não podendo tirar proveito de contextos arma-
zenados nele. Assim, todo o estado é mantido pela aplicação cliente.
As principais vantagens do padrão REST incluem uma melhora na visibili-
dade, porque todos os sistemas de monitoramento não precisam observar além
da requisição para determinar sua natureza; a confiabilidade, que tem uma
melhoria considerável uma vez que o sistema pode tratar com mais facilidade
falhas parciais; e a escalabilidade, pois o estado da aplicação não é mantido no
servidor e, por isso, não precisa gerenciar o uso dos recursos compartilhados
por requisições diferentes (FIELDING, 2000).
Como desvantagem, aumenta-se o uso dos recursos de rede, pois existe a
repetição de dados transmitidos por interação, uma vez que eles não podem
ser mantidos no servidor no contexto compartilhado, bem como retira-se
desse servidor o controle sobre a consistência do comportamento da aplicação,
porque esta se torna dependente da correta implementação no lado do cliente
(FIELDING, 2000).
Preferencialmente, as requisições devem trabalhar de forma assíncrona,
pois não é garantido o tempo de retorno, que pode variar de milissegundos a
vários segundos — ou sequer retornarem por alguma falha na conexão.
Ao responder a requisição, o servidor não guardará mais as informações na
sessão, nem dará continuidade por si só. Por exemplo, o que mantém os filtros
selecionados ao pesquisar um produto em uma loja virtual na nova pesquisa
é a aplicação que o usuário está operando, sendo essa forma de operação a
característica das arquiteturas RESTful.
 Consumo de serviços Web RESTful 11

O padrão RESTful é indicado quando cada chamada puder ser tratada como uma
transação em si. Se houver a necessidade de manter o estado da aplicação e uma
transação ser composta de diversas chamadas e trocas de mensagens, ou caso as
chamadas não forem condizentes com o uso do protocolo HTTP, convém utilizar o
Simple Object Access Protocol (SOAP). Para saber mais sobre esse protocolo, leia o capítulo
7.5 — Conceito Abstrato de Serviços e Exemplificação de Serviços do tipo SOAP, da
obra Redes de Computadores (CARISSIMI; ROCHOL; GRANVILLE, 2009).

Quando se prepara uma mensagem para ser enviada, no caso, convertendo

os objetos em uma forma que possa ser transmitida sobre HTTP, realiza-se
a serialização dos dados, que pode ser representada de diversas formas, as
mais comuns são o eXtended Markup Language (XML) e o JavaScript Object
Notation (JSON). A arquitetura RESTful tem os dados representados (ou
serializados) com esses dois padrões, mas o JSON, apesar do nome, é utilizado
por variadas linguagens de programação.

Padrões de serialização
O padrão XML é mais antigo, mas amplamente usado por se tratar de um
modelo mais rígido de serialização de dados, fornecendo maior segurança e
a integridade destes por ser mais pesado e complexo de manusear. Trata-se
do padrão de excelência em sistemas críticos, como bancos.
Já o modelo de notação JSON é bastante simples e legível, tornando-se o
padrão de escolha para a maioria das aplicações modernas que não exigem um
contrato rígido para a troca de mensagens. Nele, cada lado da aplicação ( front-
-end e back-end) tem a responsabilidade exclusiva de garantir a integridade
dos dados. Ele também utiliza menos dados por ser menos verboso, é mais
leve e suportado, nativamente, pelo JavaScript e por linguagens derivadas,
deixando o processo de serialização e desserialização mais fácil.
12 Consumo de serviços Web RESTful

Veja a representação de uma lista de dois cursos superiores de uma instituição em

formato XML:

<cursos>
<curso>
<nome>Análise e Desenvolvimento de Sistemas</nome>
<duracao-unidades>6</duracao-unidades>
<duracao-escala>semestre</duracao-escala>
<titulacao>Tecnólogo</titulacao>
</curso>
<curso>
<nome>Engenharia de Software</nome>
<duracao-unidades>8</duracao-unidades>
<duracao-escala>semestre</duracao-escala>
<titulacao>Bacharel</titulacao>
</curso>
</cursos>

Veja a representação de uma lista de dois cursos superiores de uma instituição no

formato JSON:

{
"cursos": [{
"nome": "Análise e Desenvolvimento de Sistemas",
"duracaoUnidade": "6",
"duracaoEscala": "semestre",
"titulacao": " Tecnólogo"
},
 Consumo de serviços Web RESTful 13

{
"nome": "Engenharia de Software",
"duracaoUnidade": "8",
"duracaoEscala": "semestre",
"titulacao": "Bacharel"
}]
}

Aplicação do conceito de representational state

transfer com Ionic e TypeScript
Ao trabalhar com requisições HTTP e recursos externos à aplicação, sobretudo
quando se utiliza a internet para acessá-los, tem-se um nível relativamente
alto de incerteza. Os dados podem levar mais tempo do que o previsto para
retornar, ocorrendo uma falha de comunicação ou estando indisponíveis
naquele momento.
Assim, a aplicação deve estar apta a lidar com essa incerteza. Tanto a
assincronicidade como o tratamento de exceções são elementos indispensáveis
para o correto funcionamento de uma aplicação que faça uso das chamadas
de API. A primeira serve para que o usuário não tenha a aplicação travada
enquanto o retorno da chamada não chega, dando a sensação de lentidão ou
instabilidade. Já a segunda ocorre caso essa chamada não possa ser comple-
tada, ou não se receba resposta devido ao servidor estar ausente (off-line) ou
a conexão esteja muito instável (ou indisponível).

As chamadas aos recursos externos devem ser cuidadosamente tratadas para que
não tornem a aplicação inoperante enquanto espera o retorno das informações, nem
apresentem problemas graves caso o resultado dessa chamada não retorne, por algum
problema na rede, por exemplo. Assim, o correto tratamento dessas situações influirá
diretamente na experiência do usuário com sua aplicação.
14 Consumo de serviços Web RESTful

Por exemplo, uma API de desenvolvimento retorna os dados não reais

para desenvolvimento e testes de chamadas, chamando o endpoint http://
jsonplaceholder.typicode.com/todos que retorna uma lista de tarefas (to do).

A seguir, veja um exemplo de como efetuar a chamada para URI, solicitando a lista
de usuários.
Classes de modelo de dados:

Classe de serviço que efetuará a requisição:

 Consumo de serviços Web RESTful 15

Por se tratar de um objeto Observable, precisa-se inscrevê-lo ao chamar o serviço

dentro de um componente:
16 Consumo de serviços Web RESTful

AMPUDIA, R. Celular é mais utilizado que computador para acessar internet no Brasil:
Um em cada cinco domicílios brasileiros tem acesso à internet sem ter um computador.
Folha de São Paulo, São Paulo, 2018. Disponível em: https://www1.folha.uol.com.br/
tec/2018/07/celular-e-mais-utilizado-do-que-computador-para-acessar-internet-no-
-brasil.shtml. Acesso em 12 jun. 2019.
CARISSIMI, A. S.; ROCHOL, J.; GRANVILLE, L. Z. Redes de computadores. Porto Alegre:
Bookman, 2009. 392 p. (Série Livros Didáticos Informática UFRGS, 20).
CÓDIGOS de status de respostas HTTP. Mozilla Developer Network Web Docs, [S. l.], 18
mar. 2019. Disponível em: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status.
Acesso em: 12 jun. 2019.
FIELDING, R. et al. Request for Comments: 2616: Hypertext Transfer Protocol — HTTP/1.1.
Internet Engineering Task Force, [S. l.], 1999. Disponível em: https://www.ietf.org/rfc/
rfc2616.txt. Acesso em: 12 jun. 2019.
FIELDING, R. T. Architectural Styles and the Design of Network-based Software Architectures.
Orientador: Richard N. Taylor. 2000. 180 f. Tese (Doutorado/Ph. D. em Ciência da Com-
putação e Informática) — Donald Bren School of Information & Computer Sciences,
University of California, Irvine, 2000. Disponível em: https://www.ics.uci.edu/~fielding/
pubs/dissertation/top.htm. Acesso em: 12 jun. 2019.
FOROUZAN, B. A; MOSHARRAF, F. Redes de computadores: uma abordagem top-down.
Porto Alegre: AMGH; Bookman, 2013. 917 p.
INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. Diretoria de Pesquisas. Pesquisa
Nacional por Amostra de Domicílios (PNAD) contínua: características gerais dos domi-
cílios e dos moradores 2017. Rio de Janeiro: IBGE, 2018. 30 p. Disponível em: https://
agenciadenoticias.ibge.gov.br/media/com_mediaibge/arquivos/983c56b6748df136
90bcab63b5f631c1.pdf. Acesso em: 12 jun. 2019.

Leituras recomendadas
HYPERTEXT Transfer Protocol (HTTP) Status Code Registry. Internet Assigned Numbers
Authority, [S. l.], 2018. Disponível em: http://www.iana.org/assignments/http-status-
-codes/http-status-codes.xhtml. Acesso em: 12 jun. 2019.
MACHADO, R. P.; FRANCO, M. H. I.; BERTAGNOLLI, S. C. Desenvolvimento de software III:
programação de sistemas Web orientada a objetos em Java. Porto Alegre: Bookman;
Instituto Federal de Educação Ciência e Tecnologia do Rio Grande do Sul, 2016. 220
p. (Série Tekne; Eixo Informação e Comunicação).
 Consumo de serviços Web RESTful 17

REST — PUT vs POST. REST API Tutorial, [S. l.], [201-?]. Disponível em: https://restfulapi.
net/rest-put-vs-post/. Acesso em: 12 jun. 2019.
WAGH, K.; THOOL, R. A Comparative Study of SOAP Vs REST Web Services Provisioning
Techniques for Mobile Host. Journal of Information Engineering and Applications, [S. l.], v.
2, n. 5, p. 12–16, 2012. Disponível em: https://www.iiste.org/Journals/index.php/JIEA/
article/view/2063. Acesso em: 12 jun. 2019.