APLICAÇÕES DE

INTERNET DAS
COISAS

Fabricio Machado da Silva

Web services e suas aplicações
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Descrever as características da arquitetura REST.

 Analisar as características da arquitetura SOAP.
 Exemplificar a utilização das diferentes arquiteturas de Web services.

Introdução
Um Web service é uma solução utilizada na integração de sistemas e na
comunicação entre diferentes aplicações. Com essa tecnologia, novas
aplicações podem interagir com aquelas que já existem, além de permitir
que sistemas desenvolvidos em plataformas diferentes sejam compatíveis.
Diferentes protocolos podem ser utilizados para comunicação com Web
services, com destaque para o modelo REST e para o modelo SOAP.
Neste capítulo, você vai conhecer as respectivas características de
uma arquitetura REST e de uma arquitetura SOAP. Além disso, encontrará
aplicações dessas diferentes arquiteturas de Web service.

Características da arquitetura REST

O modelo de Transferência Representacional de Estado (REST, Representatio-
nal State Transfer) foi originalmente definido por Roy Fielding em 2000. É um
estilo de arquitetura para projetar aplicativos pouco acoplados sobre HTTP e
frequentemente usado no desenvolvimento de Web services, ou serviços Web.
Comparado ao Simple Object Access Protocol (SOAP, ou Protocolo Simples
de Acesso a Objetos), o REST é um modelo bastante simplificado e leve.
Desempenho, escalabilidade, simplicidade, portabilidade e adaptabilidade
são os principais princípios por trás do design REST. A API REST permite
que diferentes sistemas se comuniquem e enviem/recebam dados de uma
maneira muito simples.
2 Web services e suas aplicações

API significa Application Programming Interface, ou Interface de Programação de

Aplicativos. Essa interface é o conjunto de padrões de programação que permite a
construção de aplicativos e sua utilização de maneira não evidente para os usuários.
API é a expansão dos aplicativos, ou seja, uma interface que roda por trás de tudo.
Enquanto você usufrui de um aplicativo ou site, a sua API pode estar conectada a
diversos outros sistemas e aplicativos, e tudo isso acontece sem que você perceba.

Cada camada da API REST tem uma relação entre um verbo HTTP e a
Uniform Resource Locator (URL). Os recursos no banco de dados em um
aplicativo podem ser mapeados com um terminal de API no REST. Quando
você usa um aplicativo móvel, seu telefone pode estar conversando secretamente
com muitos serviços em nuvem para recuperar, atualizar ou excluir seus dados.
Os serviços REST têm um enorme impacto em nossas vidas diárias. Vejamos
a seguir suas principais características:

 Arquitetura cliente/servidor: é um modelo de computação no qual o

servidor hospeda, entrega e gerencia a maioria dos recursos e serviços
a serem consumidos pelo cliente. Esse tipo de arquitetura possui um
ou mais computadores-clientes conectados a um servidor central em
uma rede ou conexão com a Internet, sob um sistema que compartilha
recursos de computação.
 Sem estado: essa é a característica mais importante de um serviço
REST. Uma solicitação HTTP REST consiste em todos os dados neces-
sários para o servidor entender e devolver a resposta. Depois que uma
solicitação é atendida, o servidor não se lembra se a solicitação chegou
depois de um tempo. Portanto, a operação será apátrida.
 Armazenamento em cache: muitos desenvolvedores creem que uma
pilha de tecnologia está bloqueando seu aplicativo da Web ou API, mas,
na realidade, sua arquitetura é a razão. O banco de dados pode ser uma
peça de ajuste em um aplicativo da Web. Para dimensionar bem um
aplicativo, precisamos armazenar em cache o conteúdo e entregá-lo
como resposta. Se o cache não for válido, é nossa responsabilidade
eliminá-lo. Os serviços REST devem ser armazenados em cache ade-
quadamente para dimensionamento.
 Web services e suas aplicações 3

 Sistema em várias camadas: a API REST pode ser veiculada em vá-

rios servidores. Um servidor pode solicitar o outro, e assim por diante.
Portanto, quando uma solicitação vem do cliente, a solicitação e a
resposta podem ser repassadas entre muitos servidores até finalmente
fornecer uma resposta ao cliente. Esse sistema multicamadas é simples
de implementar e sempre representa uma boa estratégia para manter o
aplicativo da Web fracamente acoplado.
 Representação de recursos: a API REST fornece uma interface uni-
forme com a qual conversar. Ela usa Uniform Resource Identifier (URI)
para mapear os recursos (dados). Além disso, também tem a vantagem
de solicitar um formato de dados específico como resposta. O Internet
Media Type (tipo MIME) pode informar ao servidor que o recurso
solicitado é desse tipo específico.
 Liberdade de implementação: o REST é apenas um mecanismo para
definir seus serviços da Web. Nesse sentido, nada mais é que um estilo
arquitetônico que pode ser implementado de várias maneiras. Devido
a essa flexibilidade, você pode criar serviços REST da maneira que
desejar. Até seguir os princípios do REST, seu servidor tem a liberdade
de escolher a plataforma ou tecnologia. O armazenamento em cache
cuidadoso é essencial para a expansão dos serviços REST.

No dia a dia, costumamos utilizar muitas das recomendações do REST que

foram citadas. Para passarmos a ser RESTful, basta botar em prática algumas
novas ações para que tudo se torne automático. Quem segue este modelo de
arquitetura está preparado para o crescimento do serviço sem grandes impactos,
além de oferecer aos clientes da aplicação um modelo que é de conhecimento
comum e intuitivo, evitando que cada cliente seja obrigado a aprender uma
nova arquitetura para consumir o serviço.

O REST é a abstração que usa verbos HTTP para criar serviços Web. Por sua vez, o título
de RESTful é reservado à implementação correta e em plenitude de tudo aquilo que
a arquitetura REST propicia para implementação dos serviços/APIs. Resumidamente,
é preciso adotar o conjunto das melhores práticas do REST para algo ser classificado
como RESTful.
4 Web services e suas aplicações

A Figura 1 exemplifica os conceitos e mecanismos do REST relacionados

à Web. A arquitetura utilizada é a de cliente/servidor e os recursos disponíveis
para acesso pela aplicação podem ser definidos utilizando diferentes formatos
de representações, como Extensible Markup Language (XML) e JavaScript
Object Notation (JSON).

Figura 1. Um exemplo de arquitetura REST.

Fonte: Adaptada de Lusa e Kraemer (2013).END ELEMENT

Características da arquitetura SOAP

O SOAP é um protocolo elaborado para facilitar a chamada remota de funções
via Internet, permitindo que dois programas se comuniquem de uma maneira
tecnicamente muito semelhante à invocação de páginas Web. Em comparação
a alternativas semelhantes, o SOAP possui um acoplamento mais flexível entre
o cliente e o servidor do que outros protocolos de computação distribuídos,
como o Common Object Request Broker Architecture (CORBA) em Internet
Inter-Orb Protocol (IIOP). O protocolo CORBA/IIOP define um modelo que
especifica a interoperabilidade entre objetos distribuídos em uma rede de
maneira transparente para o usuário e fornece uma comunicação mais fácil
 Web services e suas aplicações 5

para clientes e servidores que usam idiomas diferentes. O SOAP, por sua vez,
expõe uma maneira-padrão de comunicação dos processos, mas aproveita as
tecnologias existentes.
As solicitações SOAP são fáceis de gerar e um cliente pode processar facil-
mente as respostas. Um aplicativo pode se tornar um cliente programático dos
serviços de outro aplicativo, cada um trocando informações ricas e estruturadas.
A capacidade de agregar serviços Web poderosos e distribuídos permite que o
SOAP forneça um modelo de programação robusto que transforma a Internet
em uma plataforma de desenvolvimento de aplicativos.
O SOAP integra a arquitetura voltada a serviços (SOA, do inglês Service-
-Oriented Architecture) e emprega especificações de serviços da Web associa-
das à SOA. Como permite que o remetente crie uma rota de mensagem com
base nos serviços lógicos que devem ser aplicados à mensagem no caminho
para seu destino, ele se presta a fornecer conexões seguras e compatíveis,
controlando o acesso, oferecendo entrega confiável e recuperação de falhas e
dando suporte à descoberta dinâmica de serviços.
Em alto nível, o SOAP é definido em XML, mas a maioria dos aplicativos
SOAP usa Web Services Definition Language (WSDL) criada em XML. A
estrutura XML do SOAP auxilia aplicativos que esperam que suas informações
sejam fornecidas no formato XML, e o fato do SOAP poder rodar em uma
variedade de protocolos de rede, incluindo HTTP, significa que é facilmente
transmitido por firewalls mesmo em situações em que outros protocolos podem
exigir acomodação especial.
A estrutura de dados do SOAP baseada em XML é semelhante em muitos
aspectos ao HTML usado para definir páginas da Web. Assim como o HTML,
o XLM é amplamente legível por humanos, o que facilita bastante a compre-
ensão de mensagens SOAP, mas também as torna relativamente grandes em
comparação com o CORBA e o protocolo Remote Procedure Call (RPC), que
acomoda dados binários.
A maior desvantagem do SOAP (e do SOA em geral) é que se trata de um
protocolo pesado para uma arquitetura pesada. A noção de uma mensagem
atravessando uma série de nós para ser processada por cada um deles parece
misturar protocolos e modelos de arquitetura de barramento de serviço para
software, o que não é considerado ideal para o desenvolvimento baseado em
microsserviços, como o SOAP é popularmente usado.
O SOAP é um protocolo quase sempre usado no contexto de uma estrutura
de serviços Web/SOA. Como tal, sua API geralmente está oculta pela inter-
face de nível superior para SOA. Existem ferramentas de middleware da API
SOA disponíveis para quase todas as linguagens de programação modernas.
6 Web services e suas aplicações

De qualquer forma, o SOAP foi projetado para dividir os aplicativos monolíticos

tradicionais em um formulário distribuído de vários componentes sem perder
a segurança e o controle.
O SOAP foi o primeiro protocolo amplamente usado para conectar serviços
Web em SOA. Hoje, quase todos os desenvolvimentos modernos de aplicativos
distribuídos se baseiam nos princípios RESTful. O SOAP quase sempre se
limita a aplicativos e projetos herdados e, com o passar tempo, seu uso vem
diminuindo. A Figura 2 traz um exemplo da arquitetura SOAP.

Figura 2. Exemplo da arquitetura SOAP.

Fonte: Adaptada de Oracle (2001).

Utilização das diferentes arquiteturas de serviço

Nos padrões de serviços Web, as mensagens trocadas entre serviço e cliente
devem ser armazenadas em envelopes SOAP. Esse protocolo de comunicação
dita um formato de envio de mensagens entre aplicações, o qual é descentra-
lizado e distribuído, ou seja, qualquer plataforma de comunicação pode ser
utilizada, seja ela proprietária ou não (BOX et al., 2000).
Segundo Streibel (2005), esse protocolo define uma estrutura para in-
teroperabilidade entre sistemas através de mensagens XML. Um envelope
SOAP é um documento XML e o formato desse documento é definido por um
esquema XML que, por sua vez, faz uso de XML namespaces para garantir
 Web services e suas aplicações 7

extensibilidade. Um documento SOAP consiste basicamente em um elemento-

-raiz Envelope, o qual identifica o arquivo XML como sendo uma mensagem
SOAP, um elemento Header, que possui dados de cabeçalho, um elemento
Body, responsável por armazenar informações de chamadas e respostas, e um
elemento Fault, utilizado para manter informações e status de possíveis erros.
A Figura 3 ilustra a estrutura de um documento SOAP.

Figura 3. Estrutura de um documento SOAP.

Fonte: Dal Moro, Dorneles e Rebonatto (2011, documento on-line).

Quando criamos um serviço, geralmente esperamos que outras pessoas o

utilizem. Para que isso seja possível, o consumidor do serviço precisa saber
quais informações devem ser enviadas ao serviço, quais informações são
retornadas por ele e onde encontrá-lo. Um formato padronizado para essas
informações torna o consumo de um serviço mais simples. Foi com esse
objetivo que a WSDL foi adotada.
Conforme Weerawarana et al. (2005), essa linguagem de descrição foi
criada no ano 2000, originada da combinação de duas linguagens: Network
Application Service Specification (NASSL), da IBM, e Service Description
Language (SDL), da Microsoft. No ano seguinte, a versão 1.1 foi enviada
como nota para W3C e em 2007 tornou-se recomendação em sua versão
2.0. A linguagem WSDL é considerada um vocabulário XML utilizado para
descrever e localizar serviços Web. Permite que desenvolvedores de serviços
disponibilizem informações importantes para sua respectiva utilização. Além
disso, é altamente adaptável e extensível, o que permite a descrição de serviços
que se comunicam por diferentes meios, tal como SOAP.
Segundo Haines e Potts (2003), o documento WSDL é dividido logica-
mente em duas áreas: as descrições abstratas e as concretas. A parte abstrata
8 Web services e suas aplicações

descreve a capacidade do serviço Web, como mensagens recebidas e enviadas

por ele. Na parte concreta, são descritos os elementos utilizados para vincular
fisicamente o cliente ao serviço. A Figura 4 exibe a divisão lógica de um
documento WSDL.

Figura 4. Estrutura de um
documento WSDL.
Fonte: Dal Moro, Dorneles e Rebo-
natto (2011, documento on-line).

O REST, por sua vez, é o padrão mais utilizado como alternativa ao já

ultrapassado SOAP. O REST é baseado no design do protocolo HTTP, para
representar recursos com código de status. Nessa arquitetura, o fundamental
são as URLs do sistema e os recursos. Ele faz uso dos métodos HTTP para
comunicação, que são:

 GET: o método GET solicita a representação de um recurso específico.

Requisições utilizando o método GET devem retornar apenas dados.
 POST: o método POST é utilizado para submeter uma entidade a um
recurso específico, frequentemente causando uma mudança no estado
do recurso ou efeitos colaterais no servidor.
 DELETE: o método DELETE remove um recurso específico.
 PUT: o método PUT substitui todas as atuais representações do recurso
de destino pela carga de dados da requisição.

Porém, não existe um padrão obrigatório, podendo ser implementado

apenas aquilo que se faz necessário em cada contexto. A API de um serviço
 Web services e suas aplicações 9

Web é como uma estrada que liga duas cidades distantes que até então não
tinham rota direta de comunicação. No caso de aplicações, uma API pode ser
utilizada por diferentes aplicações de negócio, sem exigir que cada aplicação
conheça os detalhes da sua implementação.
Uma API pode ser acessada por meio de um endereço. Vamos supor que
estamos acessando a API disponibilizada por um serviço Web de uma escola
para pesquisar alguns registros disponíveis sobre os alunos. Perceba que
isso é uma vantagem das APIs também, pois neste exemplo os únicos dados
retornados para a nossa aplicação são o nome e a idade do aluno. Mesmo que
os registros dos alunos apresentem muitos outros dados, nossa aplicação não
tem que se preocupar com a implementação da busca em si, bastando consul-
tar o serviço Web da escola, que implementa a busca, disponibilizando, por
questões internas, apenas as informações de nome e idade.
Digamos que o endereço da API é escola.com.br/api/v1/alunos. Eis, então,
o arquivo JSON de retorno para a nossa aplicação:

{
"alunos":
[
{
"nome": "Aluno1",
"idade": 12
},
{
"nome": "Aluno2",
"idade": 13
},
{
"nome": "Aluno3",
"idade": 14
},
{
"nome": "Aluno4",
"idade": 15
}
]
}
10 Web services e suas aplicações

Com esse exemplo, podemos ver uma API em que várias aplicações-clientes
poderiam solicitar os dados dos alunos da escola e usariam essa informação. Por
sua vez, o modelo de arquitetura REST nos permite criar uma API utilizando
o protocolo HTTP para requisições.

Uma questão muito interessante, mas pouco comentada, em se tratando de serviços

Web SOAP ou REST é que ambas tecnologias podem ser misturadas e combinadas. O
REST tem como característica ser fácil de entender e ser extremamente acessível; no
entanto, carece de alguns padrões e sua tecnologia é considerada uma abordagem
arquitetural. Em contrapartida, o SOAP é o padrão da indústria, com protocolos bem
definidos e um conjunto de regras estabelecidas.

No link a seguir, você encontrará um tutorial de API REST segundo o Modelo de Ma-
turidade de Richardson (em inglês).

https://qrgo.page.link/cWUjw

BOX, D. et al. Simple object access protocol (SOAP) 1.1. [S. l.]: W3C, 2000. Disponível em:
https://www.w3.org/TR/2000/NOTE-SOAP-20000508/. Acesso em: 28 nov. 2019.
DAL MORO, T.; DORNELES, C. F.; REBONATTO, M. T. Web services WS-* versus Web services
REST. Revista de Iniciação Científica, v. 11, n. 1, p. 36-51, 2011. Disponível em: https://seer.
ufrgs.br/reic/article/viewFile/22140/12928. Acesso em: 28 nov. 2019.
HAINES, S.; POTTS, S. Java 2: primer plus. Indianapolis: SAMS, 2003.
 Web services e suas aplicações 11

LUSA, D. A.; KRAEMER, R. P. Conhecendo o modelo arquitetural REST. Devmedia, 2013.

Disponível em: https://www.devmedia.com.br/conhecendo-o-modelo-arquitetural-
-rest/28052. Acesso em: 28 nov. 2019.
ORACLE. Oracle9i Application Server Oracle9iAS SOAP Developer's Guide: Release 1 (v1.0.2.2).
Redwood City: Oracle Corporation, 2001. Disponível em: https://docs.oracle.com/cd/
A97335_02/dcommon/html/cpyr.htm. Acesso em: 28 nov. 2019.
STREIBEL, M. Implementando web services. 2005. Trabalho de Conclusão de Curso (Es-
pecialização em Web e Sistemas de Informação) - Universidade Federal do Rio Grande
do Sul, Porto Alegre, 2005.
WEERAWARANA, S. et al. Web services platform architecture: SOAP, WSDL, WS-Policy, WS-
-Adressing, WS-BPEL, WS-Reliable Messaging, and more. Upper Saddle River: Prentice
Hall, 2005.

Leituras recomendadas
BOOTH, D. et al. (ed.). Web services architecture. [S. l.]: W3C, 2004. Disponível em: http://
www.w3.org/TR/ws-arch/. Acesso em: 28 nov. 2019.
GOOGLE. Android developers. 2019. Disponível em: https://developer.android.com.
Acesso em: 28 nov. 2019.
HU, V. C. et al. Attribute-based access control. Boston: Artech house, 2018.
MAGRANI, E. A internet das coisas. Rio de Janeiro: FGV Editora, 2018.

Os links para sites da Web fornecidos nesse capítulo foram todos testados, e seu
funcionamento foi comprovado no momento da publicação do material. No entanto,
a rede é extremamente dinâmica; suas páginas estão constantemente mudando de
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade sobre
qualidade, precisão ou integralidade das informações referidas em tais links.