1

Web Service

A implementação de um software pode contemplar diferentes linguagens de programação, como Java, Python, C#,

PHP, mas devido às necessidades de integração de sistemas e comunicação entre aplicações diferentes surge o

conceito SOA com uma solução para esse problema através dos Web Services.

O que é Service Oriented Architecture (SOA)

SOA é uma arquitetura que representa funcionalidade do software como serviços, ou seja, é uma caraterização de

sistemas distribuídos, que visa organizar aplicações e sua infraestrutura, através de um conjunto de interações de

serviços que são acedidos através de interfaces e protocolos padronizados, tendo como foco processos de negócio

Os tais serviços ou funcionalidades de softwares, são disponibilizados pelos Web Services, que
têm a função de integrar aplicações web heterogêneas.
O que são Web Services

A SOA permite a criação de web services, que são serviços de software que aplicações web
disponibilizam para outras aplicações web, utilizando padrões de comunicação universais, como
JSON ou XML.
Web Services possuem diversos benefícios, tais como:
 Interoperabilidade e integração: Facilitam a comunicação e integração entre sistemas
diferentes, independente da linguagem ou plataforma;
 Reutilizável: um mesmo web service pode ser acedido por um navegador em um desktop,
um aplicativo de smartphone ou por um navegador mobile;
 Divisão de responsabilidades do sistema: web services viabilizam a separação do Front-
End do Back-End em sistemas web.
Tipos de Web Services
Existem três tipos de web services, que são: web services baseados na arquitetura REST, web
services baseados em GraphQL e web services baseados no protocolo SOAP.
 2

SOAP
Definição
De acordo com o site W3C (2000) ‘SOAP é um acrônimo para Simple Object Access Protocol,
que é um protocolo baseado na linguagem XML para a troca de mensagens entre aplicações na
internet.’
Como é baseado em XML, SOAP é independente da plataforma ou linguagem de programação e
possibilita chamadas a métodos remotos (RPC), inclusive com argumentos complexos, como se
fossem chamadas locais.
SOAP utiliza documentos WSDL para descrever os serviços, tais como: localização, métodos,
tipos de dados, etc), além disso, utiliza uma espécie de “envelope” para o envio de mensagens de
serviços web através da internet.
Funcionamento
O protocolo SOAP também é o responsável pela codificação dos dados e pelo fornecimento de
regras para que possam ser representadas e executadas as chamadas de procedimentos remotos
(RPCs) nos web services. Seu envio pela rede pode ser feito utilizando diversas tecnologias,
incluindo SMTP, HTTP, FTP entre outros.
Segundo (W3C, 2000) ‘uma mensagem SOAP é composta por três elementos que são:’
 SOAP Envelope: para definição do conteúdo da mensagem e os seus namespaces
(método para que não ocorra o conflito de nomes de elementos, tornando-os únicos na
internet, uma vez que é um documento XML, e o mesmo deve sempre ser bem
estruturado e válido);
 SOAP Header (opcional): cabeçalho que contém informações da autenticação, transação
e contabilização do web service;
 SOAP Body: que é o corpo da mensagem, no qual estão as informações dos métodos e
parâmetros a serem chamados no web service ou as respostas enviadas a este.
 3

Estrutura de uma mensagem SOAP

Síntese
Web services desenvolvidos no protocolo SOAP, tem sido muito utilizado pela indústria
de software, para integração de sistemas, em processos distribuídos e principalmente em projetos
que requerem um nível maior de segurança e confiabilidade.
REST
Definição
‘REST é um estilo arquitetural para comunicação entre aplicações na web, baseia-se no
protocolo HTTP, nos seus códigos de estados, tais como, 200(sucesso), 400(falha), 404(recurso
não encontrado) e nos seus métodos de requisição, tais como, POST (cria um novo recurso),
GET (faz a listagem dos recursos), PUT (atualiza um recurso) e DELETE (apaga um recurso)’

Esse estilo arquitetural foi criado por Roy T. Fielding na sua tese de doutoramento, que foi
realizada no ano 2000. Roy T. Fielding define REST como ‘um estilo híbrido de outras
arquiteturas de rede que são combinadas com algumas restrições adicionais definindo uma
interface de conexão única’ (Fielding, 2000).
REST é composto pelos seus princípios básicos, que quando são seguidos no processo de
desenvolvimento do web service, o mesmo é caracterizado como web service RESTful. Os
principais princípios básicos da arquitetura REST são:
 Client-Server: Separação do cliente e do armazenamento de dados (servidor), desta
forma, pode-se ter uma maior portabilidade do sistema, utilizando ReactJS para Web e
React Native para Smartphone, por exemplo;
 Stateless (sem estado): Cada requisição que o cliente faz para o servidor, deverá conter
todas as informações necessárias para o servidor entender e responder. Exemplo: A
sessão do utilizador deverá ser enviada em todas as requisições para que o servidor saiba
que aquele utilizador está autenticado e apto a utilizar os serviços, o servidor não pode
lembrar que o cliente já foi autenticado na requisição anterior;
 Cacheable: As respostas para uma requisição, devem ser explicitas ao dizer se aquela
requisição, pode ou não ser cacheada pelo cliente;
 Layered System: O cliente acede a um endpoint, sem precisar saber da complexidade, de
quais passos estão sendo necessários para o servidor responder a requisição, ou quais
outras camadas o servidor estará lidando, para que a requisição seja respondida;
 4

 Code on demand (opcional): O servidor tem a possibilidade de enviar scripts como

resposta para ser executado no lado do cliente.
Funcionamento
REST funciona baseado no protocolo HTTP, nos seus códigos de estados e nos seus
verbos que requisição e também possuí linguagens de comunicação padrão, sendo que a mais
utilizada é JSON, porém tem suporte a outras linguagens tais como, XML e Text.
REST trata objetos no servidor como recursos que podem ser criados, modificados,
removidos ou acedidos.
Tendo em conta o seu modo de funcionamento, REST viabiliza a comunicação em dois
ambientes que são:
 Client: É o consumidor do serviço e responsável pela interface gráfica, não se preocupa
com tarefas como: comunicação com a Base de Dados e Gestão de caches ou logs;
 Server: É o provedor do serviço e responsável pela comunicação com a Base de Dados e
as regras de negócio, não se preocupa com tarefas como: interface gráfica e a experiência
do utilizador.

Comunicação entre o Cliente e o Servidor

Resumindo:
REST é um modelo de arquitetura bem definido para servir aplicações web, fornece um
conjunto de recursos e padrões para construção de um web service coeso, escalável e rápido.
Seguir este modelo de arquitetura nos permite preparar para o crescimento do serviço sem a necessidade de

modelar novamente a aplicação, além de fornecer aos clientes da aplicação um modelo que é de

conhecimento comum, intuitivo, evitando a necessidade de fazê-lo entender sobre uma nova arquitetura

para consumir o serviço, pois REST funciona seguindo os princípios básico da internet (iMasters, 2014).
 5

GraphQL
Definição
GraphQL é uma linguagem de consulta para web services que fornece uma descrição completa e

compreensível dos dados, além de dar aos clientes o poder de buscar ou modificar exatamente o que eles

precisam em apenas uma requisição. Esta arquitetura possui apenas um endpoint (endereço), responsável

por lidar com todas as requisições, normalmente utilizado como ‘/graphql’. Esse endpoint aceita receber

apenas requisições HTTP que empregam o método POST (Bittencourt, 2021, p. 19).

GraphQL é uma linguagem de consulta criada pelo Facebook em 2012 e lançada

publicamente em 2015. É considerada uma alternativa para arquiteturas REST, além de fornecer
um serviço runtime (tempo de execução) para execução de comandos e consumo de um web
service.
Na figura 3, ilustra a visão geral do web service GraphQL:

Servidor GraphQL

Funcionamento
O GraphQL consiste em um sistema de tipos, linguagem de consulta e semântica de
execução, validação estática e introspeção de tipos. Ele suporta leitura (query), gravação
(mutation) e assinatura de alterações nos dados (subscription).
Tendo em conta que essa arquitetura também se baseia no protocolo HTTP, nos seus
códigos de estado e emprega apenas o método ou verbo de requisição POST, a comunicação e a
transmissão de dados entre o cliente e o servidor é mais rápida.
Nesse tipo de web service o cliente tem a maior responsabilidade e poder na
comunicação, pois é o cliente que faz a requisição para o servidor para consumir os recursos,
nesse contexto o GraphQL disponibiliza uma linguagem de consulta que tem uma sintaxe
 6

simples e intuitiva, no qual o cliente requisita o que deseja e o servidor lhe devolve exatamente
aquilo que foi requisitado, sem nada a mais ou a menos. Como se ilustra na figura 4.

Requisição do Cliente GraphQL

A figura , ilustra a resposta do servidor GraphQL

Resposta do Servidor GraphQL

Síntese
GraphQL permite que os clientes definam a estrutura de dados necessários, e a mesma
estrutura dos dados é retornada do servidor, evitando assim que um excesso ou escassez de dados
seja retornado, porém possuí implicações na eficácia e gestão de dados do resultado da consulta
armazenados em cache. A flexibilidade e a riqueza da linguagem de consulta também adicionam
complexidade que pode não valer a pena para desenvolvimento de web services simples.
 7

COMPARAÇÃO ENTRE SOAP, REST E GRAPHQL

Para o melhor esclarecimento dos tipos de web services existentes, fez-se uma breve comparação
entre os mesmos, dando destaque em algumas caraterísticas que são essenciais no processo de
comunicação entre sistemas web heterogéneos.

REST: Vantagens e Desvantagens

Vantagens Desvantagens
Adequado para desenvolvimento de projetos Consultas complexas constituem problemas
de pequeno, médio e grande porte que de over-fetching e under-fetching, gerando
possuem camadas hierárquicas. respostas que contêm dados em excesso ou
insuficientes.
Utilização de vários verbos do protocolo
HTTP, como GET, POST, PUT e DELETE, Existência de no mínimo 4 rotas para a
possibilitando a existência de mecanismos de manipulação de cada um recurso disponível
cache. no servidor.

É o tipo de web service mais popular e O cliente é obrigado a fazer múltiplas

utilizado no desenvolvimento de aplicações requisições para o servidor quando há
web. relacionamento de muitos níveis entre os
recursos.
É flexível e compatível com diversas
medidas de segurança para web services.

GRAPHQL: Vantagens e Desvantagens

Vantagens Desvantagens
Adequado para desenvolvimento de projetos Inadequado para desenvolvimento de
de grande porte. projetos de pequeno porte, por causa da
complexidade de implementação.
Existência de um único endpoint para
manipulação de todos os dados disponíveis Gestão de cache: pois utiliza apenas o
no servidor. método ou verbo de requisição POST do
protocolo HTTP.
Permite que o cliente requisite o que desejar
e como resposta receber exatamente aquilo Segurança: por causa da incompatibilidade
que requisitou, sem excesso ou escassez de com os mecanismos de segurança, demanda
dados. um maior esforço no processo de
implementação.
Possui uma linguagem de consulta de fácil
entendimento. Performance: quando se tem um elevado
número de relacionamentos, pois o mesmo
não tem suporte a funções de agregação
como por exemplo o JOIN.
 8

SOAP: Vantagens e Desvantagens

Vantagens Desvantagens
Trabalha sobre qualquer protocolo de Utiliza apenas o método ou verbo de
comunicação: os cabeçalhos estão dentro da requisição POST do protocolo HTTP.
mensagem, ou seja, eles são independentes
do protocolo de transporte da mensagem. O Por utilizar a linguagem XML, a sua
envelope SOAP pode ser transportado por mensagem consome muita largura de banda
qualquer protocolo: HTTP, SMTP, TCP, no processo de transporte.
etc...
Não pode ser armazenado em cache, pois, o
O suporte a segurança e autenticação são SOAP utiliza o método HTTP POST, o que é
melhores especificados e difundidos nos considerado não seguro, pois esse método
protocolos baseados em SOAP e XML. pode alterar os dados de um recurso.

A documentação sobre os serviços Possui um maior grau de complexidade, no

disponíveis pode ser descrita totalmente com que se refere a manipulação e interpretação
WSDL, facilitando assim o consumo dos da mensagem por causa do seu formato.
mesmos.

Síntese
Com base nas comparações feitas nas sessões acima, constatou-se que:
 SOAP: foi o primeiro tipo de web service que surgiu, na qual foi especificado o seu
funcionamento na definição da arquitetura SOA. Por ser o primeiro e o mais antigo,
SOAP utiliza a linguagem de comunicação padrão XML, que não se faz a mais viável no
processo de transporte em rede, pois consome muita largura de banda, por causa da
estrutura e o formato da mensagem que é por meio de “envelope”, que pode ser utilizado
pelos seguintes protocolos: HTTP, SMTP, TCP. Por outro lado, o “envelope” SOAP,
possui um alto nível de segurança, tendo em conta que, os conteúdos das mensagens são
encapsulados por meio do “envelope” no processo de transporte.
 REST: foi o segundo tipo de web service que surgiu, com o objetivo de permitir que
fosse possível o desenvolvimento de aplicações web totalmente adaptáveis e abertas para
integrações com terceiros e de ser uma alternativa para o SOAP. REST por sua vez,
utiliza a linguagem de comunicação padrão JSON, que é a linguagem mais adequada e
recomendada no processo de transporte de dados em rede, por causa da sua alta
performance. Por ser baseado apenas no protocolo HTTP, REST tem suporte a diversos
verbos ou métodos de requisição tais como: GET, POST, PUT e DELETE, possibilitando
assim que, os recursos possam ser manipulados no servidor com base na especificação de
 9

cada um dos métodos de requisição e também a compatibilidade com diversos

mecanismos de segurança para web services e existência de mecanismos de cache. Por
outro lado, o suporte a diversos verbos ou métodos de requisição HTTP do REST, faz
com que seja necessário a criação de no mínimo 4 rotas para a manipulação dos recursos
no servidor originando assim os inconvenientes que são denominados de: over-fetching e
under-fetching, que ocorre quando o cliente faz uma requisição para o servidor e recebe
na resposta dados em excesso ou insuficientes.
 GRAPHQL: é o tipo de web service mais recente, que foi apresentado como uma
alternativa para o REST, possuindo como principal objetivo a resolução dos
inconvenientes do REST que são: over-fetching e under-fetching. GRAPHQL também
baseia-se no protocolo HTTP mas tem suporte apenas ao verbo ou método de requisição
POST. Por possuir apenas um endpoint, GRAPHQL permite que o cliente faça requisição
do que desejar e receber na resposta exatamente aquilo que requisitou, sem dados em
excesso ou insuficientes. Em contrapartida, por possuir apenas um endpoint e ter suporte
apenas a um verbo de requisição, GRAPHQL faz-se muito complexo e custoso no
processo de implementação de mecanismos de gestão de cache e de segurança.
Deste modo, não existe o melhor ou o que atende a todas as demandas e tipos de
aplicações web, mas sim, o que melhor se adequa e vai de encontro a realidade específica de
cada projeto de software que se pretende implementar.