Web Services: Conceitos e Funcionalidades

Prévia do material em texto

Aula 32 (Profs Diego
Carvalho e Fernando
Pedrosa)
Concursos da Área Fiscal - Curso Básico
de Tecnologia da Informação - 2023
Autor:
Fernando Pedrosa Lopes , Thiago
Rodrigues Cavalcanti, Erick
Muzart Fonseca dos Santos,
Paolla Ramos e Silva , Diego
Carvalho, Renato da Costa, Equipe
Informática e TI
12 de Junho de 2023
https://t.me/kakashi_copiador
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Índice
..............................................................................................................................................................................................1) WS e REST 3
..............................................................................................................................................................................................2) Questões Comentadas - WS e REST - Multibancas 25
..............................................................................................................................................................................................3) Lista de Questões - WS e REST - Multibancas 35
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
2
42
WEB SERVICES 
Conceitos Básicos 
INCIDÊNCIA EM PROVA: média 
 
Como esse é um tema mais técnico, eu vou precisar fazer uma grande contextualização para que 
o assunto faça sentido para vocês. Quando começaram a surgir as primeiras redes de 
computadores, o processamento de dados era centralizado em poucos servidores que não se 
comunicavam entre si. Com o passar do tempo, foram surgindo redes em todo lugar – tanto 
pública quanto privada –, formando esse emaranhado de redes que existem atualmente. 
 
Essas redes começaram a se comunicar e as aplicações que hospedadas em poucos servidores 
passaram a ser hospedadas de forma distribuída em vários servidores – surgiram, então, as 
aplicações distribuídas. Ora, aplicações diferentes dentro de uma mesma organização 
precisavam se comunicar, assim como aplicações de organizações diferentes. Para resolver esse 
problema, surgiram os Web Services (Serviços Web). 
 
Os web services têm a missão de fazer a integração sistemas heterogêneos. Como assim, 
professor? Softwares são desenvolvidos com linguagens de programação diferentes (Ex: Java, 
Python, C, Go, JavaScript), para arquiteturas diferentes (Ex: x86, x64), para sistemas 
operacionais (Ex: Windows, Linux, MacOS), para dispositivos diferentes (Ex: Desktop, Mobile), 
entre outros. Ora, como fazer tudo isso se comunicar? Por meio dos Web Services! 
 
Agora vamos destrinchar esse ponto: o que é um serviço no contexto de engenharia de software? 
Trata-se de um mecanismo que permite acessar um conjunto de recursos, no qual o acesso é 
fornecido por meio de uma interface descrita e exercitada consistentemente de acordo com 
restrições e políticas especificadas pela descrição do serviço. Professor, eu não compreendi uma 
palavra do que você disse! Calma, aos poucos isso vai fazer sentido! Vamos ver outras definições: 
 
Definições de Web Services 
Web Services tratam da disponibilização de um serviço pela internet que pode ser acessado em qualquer lugar. 
 
Web Services são componentes de aplicativos baseados em XML, autocontidos e autodescritivos, que se 
comunicam usando protocolos abertos. 
Web Services são uma interface que descreve uma coleção de operações que são acessíveis pela rede através 
de mensagens XML padronizadas. 
Web Services tratam essencialmente da interoperabilidade entre programas e aplicações – especialmente 
quando eles usam linguagens, ferramentas ou plataformas diferentes. 
Web Services são um sistema de software projetado para permitir interoperabilidade na interação entre 
máquinas através de uma rede. 
Web Services são componentes de software com baixo fator de acoplamento, utilizado por meio de padrões de 
internet. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
3
42
Web Services representam uma função/lógica de negócio ou um serviço que pode ser acessado por uma outra 
aplicação na web, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos. 
Web Services são soluções utilizadas na integração de sistemas e na comunicação entre aplicações diferentes, 
permitindo que elas enviem e recebam dados. 
 
Web Services são, portanto, componentes de software que permitem a integração de 
aplicações distribuídas desenvolvidas com tecnologias heterogêneas, por meio do 
fornecimento de serviços de baixo acoplamento, protocolos abertos e interfaces bem definidas 
a fim de garantir a comunicação e interoperabilidade no envio e recebimento de dados entre 
máquinas dispostas em redes de computadores. 
 
CARACTERÍSTICA DESCRIÇÃO 
WEB SERVICES SÃO 
AUTOCONTIDOS 
Isso significa que eles não necessitam ou dependem de outros componentes 
para ter uma existência própria. 
Web services são 
autodescritivos 
Isso significa que eles não necessitam de informações externas para expor suas 
funcionalidades. 
Web Services utilizam 
protocolos abertos 
Isso significa que os protocolos não são de propriedade de nenhuma 
organização, são apenas protocolos padrões da internet. 
Web services são fracamente 
acoplados 
Isso significa que a interface do serviço pode mudar sem comprometer a 
capacidade do cliente de interagir com o serviço. 
Web services são 
independentes de tecnologia 
Isso significa que eles são independentes de plataforma, sistema operacional, 
arquitetura de processador, linguagem de programação, entre outros. 
 
Galera, vamos agora fazer uma comparação para ficar mais claro! Há alguns meses, eu (cliente 
de serviço) decidi mudar de operadora de celular (provedor de serviço). Eu fui até o shopping 
mais próximo, entrei na loja específica, escolhi o plano que se adequava às minhas necessidades 
e fui assinar o contrato de serviço. O que é um contrato? É um documento que formaliza um 
acordo entre duas ou mais partes. Qual era o acordo que eu estava firmando? 
 
No meu caso, eu pagaria mensalmente uma quantia em reais todo dia 10. Em troca, eles me 
ofereceriam o serviço de ligações ilimitadas e um pacote de internet. É claro que o contrato tem 
várias outras especificações em relação ao objeto, à prestação do serviço, aos direitos e deveres, 
à contestação de débitos, à suspensão da prestação do serviço, ao extravio do chip, à vigência, à 
rescisão, ao atendimento ao cliente, entre outros. 
 
Agora vejam que a ideia aqui é semelhante: web service é um serviço! Vocês se lembram da 
definição de serviço? Trata-se de um mecanismo que permite acessar um conjunto de recursos, 
no qual o acesso é fornecido por meio de uma interface descrita e exercitada consistentemente 
de acordo com restrições e políticas especificadas pela descrição do serviço. Viram como é 
semelhante ao serviço da operadora de celular? 
 
Ela oferece um mecanismo que permite acessar um conjunto de recursos (ligações e internet), 
no qual o acesso é fornecido por meio de uma interface descrita e exercitada consistentemente 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
4
42
de acordo com restrições e políticas especificadas pela descrição do serviço (contrato).A 
disponibilização de um serviço ocorre por meio de um contrato, que é uma interface padronizada 
que disponibiliza suas funcionalidades. 
 
Qual é a grande vantagem da interface, professor? Galera, a interface permite que dois ou mais 
sistemas se comuniquem de forma transparente, isto é, sem se preocupar com detalhes de 
implementação. Vamos voltar à metáfora: quando eu assino o contrato (interface) com a 
operadora celular, ela não quer saber o que eu vou ter que fazer para pagar o valor mensal e eu 
não quero saber o que ela vai ter que fazer para oferecer o serviço de telefonia e internet móvel. 
 
O que importa para mim é o serviço sendo prestado conforme as condições do contrato e o que 
importa para ela é receber a grana mensalmente na data acordada. É semelhante com os 
serviços web: quando um provedor oferece um serviço a um cliente, o cliente não está nem 
aí para como o serviço será implementado – ele só quer consumir o serviço da forma como 
está descrito em sua interface e ponto final. Essa é a beleza dos serviços web... 
 
Bem, vamos ver um exemplo de Web Service? Vamos! Eu escolhi ver os dados abertos da Câmara 
dos Deputados. Quem quiser acessá-los, acesse o link a seguir: 
 
https://www2.camara.leg.br/transparencia/dados-abertos/dados-abertos-legislativo/webservices/deputados 
 
Notem que essa página apresenta um Web Service! Logo, ela deve possuir uma interface 
(contrato) que define os serviços que são oferecidos por meio de métodos: 
 
 
 
Nesse contexto, nós somos clientes de serviços e a página é o provedor de serviço. Que serviços 
ela oferece? Ela permite listar os deputados em exercício; listar detalhes dos deputados com 
histórico de participação em comissões, períodos de exercício, filiações partidárias e lideranças; 
listar os deputados líderes e vice-líderes em exercício das bancadas dos partidos; listar os 
partidos com representação; e listar os blocos parlamentares. 
 
Professor, como eu faço efetivamente para utilizar esses serviços? Eu preciso saber o endpoint do 
serviço (URL). Notem que a página informa o endereço do endpoint: 
 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
5
42
 
Esse endpoint exibe todos os serviços oferecidos, mas é possível acessar cada um 
individualmente. Como, Diego? Basta utilizar os nomes dos métodos exibidos anteriormente: 
 
https://www.camara.leg.br/SitCamaraWS/Deputados.asmx/ObterDeputados 
 
O endereço acima contém ao final o método ObterDeputados, que lista todos os deputados 
dessa casa legislativa. Se eu acessar os detalhes do contrato, vou encontrar algo assim: 
 
 
 
Acima está uma espécie de contrato do Web Service. Como assim, Diego? Ele está dizendo que, 
se eu acessar esse serviço web por meio do endereço apresentado anteriormente (sem nenhum 
parâmetro), ele me retornará a lista de todos os deputados em exercício com diversos dados dos 
deputados, tais como Nome, Matrícula, Sexo, UF, Partido, Gabinete, Anexo, Telefone, E-Mail, 
etc. Vamos fazer um experimento? Testem aí no navegador de vocês – o resultado será algo assim: 
 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
6
42
 
O resultado veio em formato XML (formato de dados adotado pela W3C para troca de 
informações entre aplicações distribuídas). Note que ele trouxe diversos dados da deputada 
Benedita Souza da Silva Sampaio. Agora notem: eu (cliente) cumpri a minha parte e fiz uma 
requisição web respeitando o formato do endereço do endpoint e ele fez a parte dele me 
retornando uma resposta que respeita o formato acordado no contrato. Coisa linda, não é? 
 
Vamos fazer um teste um pouco mais complexo agora! Se eu mudar o finalzinho do endereço 
anterior para ObterDetalhesDeputado, eu consigo listar histórico de participações, etc. 
 
https://www.camara.leg.br/SitCamaraWS/Deputados.asmx/ObterDetalhesDeputado 
 
No entanto, vendo os detalhes do contrato desse método, é possível verificar que ele permite 
receber alguns parâmetros de entrada para filtrar os resultados de saída. Vejamos: 
 
 
 
Ela permite inserir o identificador do deputado e o número de sua legislatura para filtrar os 
detalhes do deputado com histórico de participação em comissões, períodos de exercícios, 
filiações partidárias e lideranças. Para visualizar os dados detalhados da deputada Benedita 
Souza da Silva Sampaio, eu vou inserir o seu identificador de cadastro (73701) e o número da 
legislatura (55) – ambos os dados estavam no resultado do serviço web visto anteriormente. 
 
O resultado é apresentado a seguir: é apresentado e-mail, profissão, data de nascimento, estado, 
sexo, partido e, além disso, é mostrado o histórico de quais comissões ela participou nessa 
legislatura (Ex: CREDN – Comissão de Relações Exteriores e de Defesa Nacional – Entrada em 
15/04/2015 e saída em 02/02/2016). Caso eu não informe o parâmetro da legislatura, será 
retornado o histórico de todas as legislaturas de que a deputada participou. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
7
42
 
 
Está ficando mais claro? Vocês viram que há um contrato que define a interface do serviço web 
disponível e que, caso o cliente faça a requisição do serviço por meio da sintaxe correta do 
endereço de seu endpoint, serão retornadas as informações exatamente de acordo com o que 
estava descrito no contrato. Professor, eu achei muito feio esse formato de saída das informações 
dos web services... 
 
Galera, o formato XML é utilizado para representar e transportar dados de forma que possa 
ser lido tanto por máquinas quanto por humanos. Perceba que a ideia desse formato não é 
exibir uma saída visualmente bonitinha – é simplesmente representar e transportar os dados. 
Aliás, agora vem a grande sacada: caso uma aplicação queira se integrar com as aplicações da 
Câmara dos Deputados, ela poderá fazê-lo por meio por meio de Web Service! Como é, Diego? 
 
Imagine que eu crie uma ONG (Organização Não-Governamental) cujo intuito é fiscalizar o 
trabalho dos deputados federais. Para facilitar o trabalho dos fiscais que eu contratei para a 
minha ONG, seria interessante desenvolver uma aplicação de software. Além disso, é óbvio que 
a minha aplicação deveria ter acesso aos dados oficiais da Câmara dos Deputados! O que eu 
poderia fazer para realizar essa integração? 
 
Eu poderia entrar em contato com área de tecnologia da Câmara dos Deputados e perguntar 
quais tecnologias são utilizadas para fazer a programação, qual é o sistema gerenciador de banco 
de dados utilizado, quais eram os dados disponíveis, entre outros. Para quê? Para tentar fazer 
com que a minha aplicação (que eventualmente pode ser feita utilizando tecnologias diferentes) 
se comunique de forma compatível com a aplicação dessa casa legislativa. 
 
Vamos supor que, por um milagre do destino, eu consiga fazer toda essa integração entre os 
sistemas! O que aconteceria se eventualmente eles mudassem alguma tecnologia? E se eles 
mudassem a implementação do sistema? E se eles mudassem de sistema gerenciador de banco de 
dados? E se eles mudassem o formato de armazenamento dos dados? Tudo isso poderia impactarde forma negativa a integração e a comunicação entre os dois sistemas. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
8
42
 
O ideal, portanto, seria fazer a integração dos sistemas por meio de um Web Service. A utilização 
de serviços web permite que todas essas mudanças ocorram indiscriminadamente desde que 
a interface (contrato) permaneça a mesma. Como é, Diego? É isso mesmo! A Câmara dos 
Deputados pode fazer a alteração que quiser: se ela mantiver a interface imutável, meu sistema 
sequer vai perceber que houve mudanças – será transparente para ele. 
 
Essa é a grande sacada dos serviços web: aplicações distribuídas que foram desenvolvidas com 
tecnologias completamente diferentes podem ser comunicar por meio de serviços de baixo 
acoplamento, protocolos abertos e interfaces bem definidas. Clientes enviam requisições com 
informações bem definidas e recebem respostas também bem definidas de forma síncrona ou 
assíncrona. E mais: uma vez descrito, padronizado e catalogado, o serviço se torna reutilizável. 
 
Vejam que bacana: o serviço web permite a interoperabilidade entre aplicações distribuídas, não 
é necessário conhecer sua implementação, possibilita a comunicação com novas aplicações ou 
também com aplicações legadas, é reutilizável e independente de tecnologia, utiliza protocolos 
padronizados e padrões abertos (não proprietários), melhora a usabilidade, possui baixo 
acoplamento, reduz os custos, não requer a interação de usuários finais1, entre outros. 
 
 
 
1 Há implementações de Web Services que tratam da interação máquina-máquina ou aplicação-aplicação – sem a obrigatoriedade de interferência 
humana. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
9
42
Arquitetura de Web Services 
INCIDÊNCIA EM PROVA: média 
 
A arquitetura de Web Services envolve basicamente três categorias de participantes: Provedor 
de Serviço (Service Provider), Solicitante do Serviço (Service Requester) e Agente de Serviço 
(Service Broker). Quem é o provedor de serviço? É qualquer aplicação que forneça serviços web. 
Quem é o solicitante do serviço? É qualquer aplicação que deseje utilizar serviços web. E quem é o 
agente de serviço? É qualquer aplicação que faça a intermediação entre provedor e solicitante. 
 
Quem aí já investiu na bolsa de valores? Para você comprar ou vender ações, é necessário ter 
acesso a um Home Broker! O que é isso? É um sistema que atua na intermediação da compra e 
venda de valores mobiliários de investidores. Por exemplo: eu uso o Home Broker para fazer uma 
oferta de compra de uma ação e outro investidor também o utiliza para fazer uma oferta de 
venda. Se nossas ofertas forem compatíveis, o negócio é fechado! 
 
Com os serviços web, ocorre de maneira bastante semelhante! Um Service Broker faz a 
intermediação entre o Service Provider e o Service Requester. O fornecedor de serviços publica os 
seus serviços disponíveis no agente de serviços e o solicitante pesquisa por serviços que o 
satisfaçam. É importante destacar que quando um fornecedor e um solicitante entram em 
acordo, ocorre o que chamamos de Bind (Vínculo). 
 
Paradigma SOAP 
 
Galera, agora vamos começar a falar de termos mais técnicos! Uma das formas de realizar a 
comunicação entre serviços web é por meio de três padrões fundamentais: 
 
PADRÕES DESCRIÇÃO 
SOAP (SIMPLE/SINGLE OBJECT 
ACCESS PROTOCOL) 
Baseado em XML, define uma organização para troca estruturada de dados entre 
Web Services. 
WSDL (WEB SERVICES 
DESCRIPTION LANGUAGE) 
Baseado em XML, define como as interfaces dos Web Services podem ser 
representadas. 
UDDI (UNIVERSAL DESCRIPTION, 
DISCOVERY AND INTEGRATION) 
Baseado em XML, trata-se do padrão de descobrimento que define como as 
informações podem ser organizadas. 
 
Professor, há outras maneiras de implementar serviços web? Sim, existem outras tecnologias e 
paradigmas – os principais são os Paradigmas SOAP e REST! Vamos iniciar falando sobre o 
primeiro, já que ele é o mais antigo. Bem, a tabelinha apresentada acima é muito muito muito 
importante – ela sozinha permite responder dezenas ou até centenas de questões de provas. 
Essa é a base para os serviços web do Paradigma SOAP. 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
10
42
No entanto, com o passar do tempo, começaram a surgir 
algumas lacunas de qualidade – especialmente nas áreas de 
segurança relacionadas a criptografia, assinatura digital, 
autorização, conversação, federação, políticas de 
segurança, privacidade, entre outros. Surgiram, então, 
diversas extensões para fornecer um conjunto sofisticado 
de componentes construídos para suprir essas lacunas. Esse 
conjunto de extensões de segurança ficou conhecido 
como WS-Security. 
 
Em seguida, surgiram outras especificações relacionadas a outros temas, como processos de 
negócio, mensageria, especificação de metadados, especificação de recursos, especificação de 
gerenciamento, interoperabilidade, transações, entre outros. Esse conjunto de especificações 
com suas respectivas extensões foram chamados de WS-*. O que você precisa guardar é que 
o escopo foi aumentando cada vez mais... 
 
SOAP 
INCIDÊNCIA EM PROVA: Altíssima 
 
DEFINIÇÃO DE SOAP 
Trata-se de uma das formas de comunicação para encapsular dados transferidos no formato XML para Web 
Services. 
Trata-se de um formato baseado em XML para intercâmbio de mensagens – é utilizado para realizar o 
encapsulamento e o transporte de dados. 
Trata-se de um formato para envio e recebimento de mensagens independentemente de plataforma e 
tecnologia. 
Trata-se de um protocolo baseado em XML que define uma organização para a troca estruturada de dados 
entre Web Services. 
 
Um dos motivos que tornam os serviços web tão atrativos é o fato de serem baseados em 
tecnologias padrão. Como assim, Diego? Existe uma organização de padronização da web 
chamada W3C (WWW Consortium). Ela agrega empresas, órgãos governamentais e 
organizações independentes com a finalidade de estabelecer padrões para a criação e a 
interpretação de conteúdos para a web. 
 
Em outras palavras, essa organização recomenda um conjunto de tecnologias e formatos 
aprovados para que sistemas web possam se comunicar sem problemas. Vocês já imaginaram se 
alguém cria um componente em uma página web com uma tecnologia proprietária que eu só consigo 
acessar se eu tiver que pagar por aquela tecnologia? Complicaria toda a interação entre 
componentes web. 
 
A W3C recomenda padrões como XML, HTML, PNG, SVG, XHTML, CSS, etc – todos eles são 
abertos, logo não são de propriedade de nenhuma organização e podem ser utilizados 
livremente. Pois bem... os serviços web utilizam tecnologias padrão da internet como XML e 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
11
42
HTTP. Essas tecnologias são comumenteutilizadas para disponibilizar serviços web, podendo 
ser acessados por outras aplicações. 
 
Nesse contexto, temos o SOAP! Trata-se de um protocolo baseado na linguagem XML para a 
troca de mensagens. Ele foi projetado para invocar aplicações remotas em um ambiente 
independente de tecnologias, sendo o padrão para serviços web que utilizem o Paradigma 
SOAP. É importante destacar que XML é apenas a linguagem comum para intercomunicação 
entre diferentes sistemas, mas o protocolo utilizado para transportar a mensagem é HTTP. 
 
Professor, é obrigatório utilizar esse protocolo para envio/recebimento de informações entre serviços 
web? Não, é possível utilizar outros protocolos (Ex: SMTP), mas esse é o protocolo padrão da 
web, logo ele é o mais utilizado atualmente (inclusive em outros paradigmas). Professor, está 
começando a ficar muito abstrato e eu não estou conseguindo acompanhar! Então vamos passar 
para alguns pontos mais concretos... 
 
O que é o SOAP? É um protocolo! Para quê? Para a troca estruturada de dados entre serviços web 
em redes de computadores. Ele não é um formato? Sim, esse protocolo especifica um formato 
comum de mensagens. Baseado em quê? Baseado na linguagem XML. E o que é o XML? É uma 
linguagem de marcação que permite definir um conjunto de regras para troca de dados, podendo 
ser compreendida tanto por humanos quanto por máquinas. 
 
Vamos conhecer o tal do formato especificado pelo SOAP? O SOAP consiste basicamente dos 
elementos descritos na tabela seguinte: 
 
ELEMENTOS Situação DESCRIÇÃO 
ENVELOPE 
(ENVOLOPE) 
obrigatório 
Trata-se do elemento-raiz do documento XML. Ele identifica o documento XML 
como uma mensagem SOAP e funciona como um recipiente que contém os demais 
elementos da mensagem (Ex: Header e Body). Corresponde à descrição da 
mensagem e do que deve ser processado. 
CABEÇALHO 
(HEADER) 
OPCIONAL 
Trata-se do elemento que carrega informações adicionais específicas para a aplicação 
a fim de estender as funcionalidades das Mensagens SOAP. Desta forma, é possível 
adicionar novas funcionalidades como autenticação, criptografia, autorização, 
assinatura digital, etc. Podem ser definidos vários cabeçalhos. 
CORPO 
(BODY) 
OBRIGATÓRIO 
Trata-se do elemento que contém a carga útil (payload) da Mensagem SOAP. É aqui 
que estão as informações propriamente ditas do serviço web remetidas ao 
destinatário final da mensagem, incluindo a chamada ao procedimento ou o retorno 
de seu resultado. 
Falha 
(fault) 
Opcional 
Trata-se do elemento contido no corpo responsável por relatar possíveis erros de 
envio ou processamento de mensagens, informando localização e formato dos erros 
encontrados. Quando estiver presente deve aparecer como um elemento filho do 
elemento Body. 
 
Vamos ver como é uma Mensagem SOAP? No exemplo a seguir, temos uma requisição em que é 
chamado um procedimento chamado retornaNome, que recebe CPF como parâmetro: 
 
POST /InStock HTTP/1.1 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
12
42
Host: www.dre.ufrj.br 
Content-Type: application/soap+xml; charset=utf-8 
Content-Length: nnn 
 
<?xml version="1.0"?> 
 
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap- envelope" 
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:tiposns="http://www.w3.org/2001/XMLSchema"> 
 
 <soap:Header> 
 <m:atenticacao xmlns:m="http://www.dre.ufrj.br/ws/dre">21423edf69fgs</m:atenticacao> 
 </soap:Header> 
 
 <soap:Body> 
 <m:retornaNome xmlns:m="http://www.dre.ufrj.br/ws/dre"> 
 <numdre type="tiposns:int">123.456.789-00</drenum> 
 </m:retornaNome> 
 </soap:Body> 
 
</soap:Envelope> 
 
Notem que, em verde, temos o envelope; em laranjado, temos o cabeçalho (que adiciona uma 
funcionalidade de autenticação); e, em azul, temos o corpo (que recebe o CPF). E a resposta: 
 
HTTP/1.1 200 OK 
Content-Type: application/soap+xml; charset=utf-8 
Content-Length: nnn 
 
<?xml version="1.0"?> 
 
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap- envelope" 
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:tiposns="http://www.w3.org/2001/XMLSchema"> 
 
 <soap:Header> 
 <m:atenticacao xmlns:m="http://www.dre.ufrj.br/ws/dre">2kg469fgs</m:atenticacao> 
 </soap:Header> 
 
 <soap:Body> 
 <m:retornaNomeResponse xmlns:m="http://www.dre.ufrj.br/ws/dre"> 
 <nome type="tiposns:string">João da Silva</nome> 
 </m:retornaNomeResponse> 
 
 <soap:Fault> 
 </soap:Fault> 
 
 </soap:Body> 
 
</soap:Envelope> 
 
Notem que a resposta do serviço web retornou o nome João da Silva para o CPF informado como 
parâmetro. Vejam também que há, em amarelo, o elemento fault vazio, porque não houve 
falhas. Professor, eu preciso entender esse código em detalhe? Não, pessoal... basta saber a função 
dos quatro elementos. Vejam que não é difícil identificá-los em uma Mensagem SOAP! Você faz 
uma requisição e recebe uma resposta como resultado. 
 
WSDL 
INCIDÊNCIA EM PROVA: Altíssima 
 
DEFINIÇÃO DE WSDL 
Trata-se de uma linguagem de descrição de web services, escrita em XML, para descrever serviços web, 
especificar as formas de acesso, as operações/métodos disponíveis. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
13
42
Trata-se de uma linguagem para descrever serviços de rede como endpoints (ou portas) que operam em 
mensagens que contêm informações orientadas à documento/procedimento. 
Trata-se efetivamente de especificação que define como descrever serviços web em uma gramática XML. 
 
Trata-se de um protocolo baseado em XML para troca de informações em ambientes distribuídos e 
descentralizados (sim, alguns autores o consideram também como um protocolo). 
 
Vocês já pensaram de que forma um cliente de um serviço web sabe qual formato dos métodos a 
serem chamados? Quais os parâmetros que devem ser passados? Como se deve processar uma 
requisição específica? Para responder a essas questões, criou-se uma linguagem para 
padronizar as descrições das funcionalidades oferecidas por um Web Service. Trata-se de uma 
linguagem para descrição de serviços web. 
 
Baseada em XML, é utilizada para descrever um Web Service e deve, portanto, definir todas as 
suas interfaces, operações, métodos, parâmetros, esquemas de codificação, portas de 
comunicação, protocolos, formatos de mensagens, entre outros. Tão logo o cliente tenha 
acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita 
em qualquer linguagem de programação. 
 
Quando um cliente deseja enviar uma requisição para um serviço web, ele obtém a descrição 
do serviço e, em seguida, constrói a mensagem de acordo com a especificação da descrição 
encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço 
está localizado, a fim de que possa ser processada. O serviço web recebe a mensagem e realiza 
uma validação conforme as informações contidas no Documento WSDL. 
 
Vamos recapitular? O SOAP é o protocolo responsável por especificar a organização das 
mensagens trocadas entre o cliente e o fornecedor de serviços web, isto é, a composição da 
estrutura das mensagens. Já o WSDL é o documento que, resumidamente, descreve quais são as 
operações disponíveis em um serviço web com todasas particularidades de suas interfaces como 
métodos, parâmetros, protocolos, entre outros. Vamos aprofundar um pouco mais? 
 
WSDL separa a descrição de um serviço em duas perspectivas: 
Abstrata e Concreta! A perspectiva abstrata trata da interface do 
serviço. Em outras palavras, descreve o que o serviço faz: 
parâmetros, tipos, operações, entradas, saídas, mensagens fault, 
etc. Já a perspectiva concreta trata da implementação do serviço. 
Em outras palavras, descreve como o serviço é feito: protocolos 
de comunicação, codificação de dados, localização, portas, 
endereço de rede, etc. Ela também adiciona informações sobre 
como o serviço se comunicará e quem pode alcançá-lo. 
 
Professor, qual a vantagem de fazer essa separação? A vantagem é que, caso a implementação 
(perspectiva concreta) do serviço seja modificada por alguma razão, a interface (perspectiva 
abstrata) pode continuar a ser disponibilizada sem problemas – e até reutilizada para diversas 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
14
42
implementações diferentes. Por fim, o WSDL define quatro padrões de mensagens suportadas 
para quatro tipos de operações: 
 
TIPO DEFINIÇÃO 
ONE-WAY A operação pode receber uma requisição, mas não retornará uma resposta. 
REQUEST-RESPONSE A operação pode receber uma requisição e retornará uma resposta. 
SOLICIT-RESPONSE A operação pode enviar uma requisição e esperará por uma resposta. 
NOTIFICATION A operação pode enviar uma mensagem, mas não esperará por uma resposta. 
 
UDDI 
INCIDÊNCIA EM PROVA: Altíssima 
 
DEFINIÇÃO DE UDDI 
Trata-se de um serviço de diretório, baseado em XML, em que é possível registrar e localizar Web Services. 
 
Trata-se de uma especificação técnica que tem como objetivo descrever, descobrir e integrar Web Services. 
 
Trata-se de um diretório/registro para armazenamento de informações sobre Web Services – é um repositório 
de interfaces de Web Services descritas por WSDL. 
Trata-se de um protocolo que é um dos maiores blocos de construção requeridos para construir Web Services 
com sucesso (Sim, alguns o chamam de protocolo!). 
Trata-se de um padrão de descoberta que define como são organizadas as informações de descrição do serviço, 
permitindo que os solicitantes descubram os serviços. 
 
Galera, nós já sabemos que o SOAP é responsável por especificar a organização para a troca de 
mensagens entre serviços web e também sabemos que o WSDL é responsável por nos descrever 
a interface das operações disponíveis em um serviço web. Agora uma pergunta: como eu vou 
encontrar um serviço web? Aonde eu procuro? Onde eles estão? O que comem? Onde vivem? Para 
responder a essas perguntas, existe o UDDI! 
 
Quando se constrói um serviço web, ele deve ser disponibilizado em algum lugar para que seja 
acessível por diversas aplicações-cliente. O UDDI é uma especificação técnica, ou protocolo e 
um serviço de diretório onde empresas podem registrar, publicar, descrever, buscar, 
descobrir e integrar serviços web. Ele contém informações genéricas sobre a provedores de 
serviços web, implementações e metadados básicas sobre eles. 
 
Vamos testar a faixa etária dos meus alunos agora! Alguém sabe 
o que é esse livro da imagem ao lado? Galera, isso é uma lista 
telefônica. Quando o telefone fixo começou a se popularizar, 
todas as casas e empresas possuíam seus telefones. E se acabasse 
o gás na minha casa e eu precisasse ligar em uma companhia de gás 
para terminar meu almoço, jovem? Não tinha internet! Você tinha 
que pegar sua pesada lista telefônica e pesquisar nas páginas 
amarelas por empresas de gás para descobrir seu telefone. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
15
42
 
A lista telefônica era dividida em duas partes: as páginas brancas continham os nomes e os 
números de telefone não comerciais (isto é, residenciais) e as páginas amarelas continham os 
nomes e os números de telefone comerciais (isto é, empresariais). O que isso tem a ver com a aula, 
Diego? O UDDI era basicamente uma Lista Telefônica! Ambos eram um serviço de diretório 
para registrar, publicar, descrever, buscar, descobrir e integrar telefones ou serviços web. 
 
Essa metáfora é tão óbvia que está na própria teoria dos serviços web. Como assim, professor? 
Galera, as informações capturadas no contexto do UDDI podem ser classificadas em três 
categorias principais: Páginas Brancas, Páginas Verdes ou Páginas Amarelas. No entanto, 
evidentemente aqui elas possuem um significado um pouco diferente do significado das listas 
telefônicas de antigamente... 
 
 
 
As Páginas Brancas contêm informações gerais sobre a organização que está oferecendo o 
serviço web, tais como nome e descrição do negócio (de preferência, em diversas línguas). 
Utilizando essas informações, é possível encontrar algum serviço sobre o qual já se pode 
conhecer algumas informações. Há também informações de contato do negócio (Ex: Endereço, 
Telefone, Fax, Identificadores, etc). 
 
A Páginas Amarelas contêm uma classificação do serviço ou negócio disponíveis baseado em 
taxonomias padronizadas (Ex: SIC, NAICS, UNSPSC). Como é, Diego? As Páginas Amarelas 
usam os esquemas de categorização industrial mais aceitos no mercado, códigos de indústria, 
códigos de produtos, códigos de identificação comerciais e similares para tornar mais fácil para 
as empresas procurarem por meio de listas e encontrarem exatamente o que elas desejam. 
 
Professor, eu ainda não entendi! Por exemplo: UNSPSC (United Nations Standard Products and 
Services Code) é uma taxonomia de produtos e serviços para e-commerce. Ela possui um 
conjunto de códigos que permitem classificar e identificar uma organização quanto ao setor 
comercial. Sacaram? Já as Páginas Verdes contêm informações mais técnicas sobre como 
acessar um serviço web. 
 
Elas são utilizadas para indicar os serviços oferecidos por cada negócio, incluindo todas as 
informações técnicas envolvidas na interação e acesso ao serviço. Em geral, essas informações 
incluem uma referência para uma especificação externa e um endereço para invocar o serviço. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
16
42
Por meio do UDDI, é possível encontrar os contados do dono do serviço web, seu setor de 
serviço, algumas informações técnicas e uma referência para o WSDL. 
 
O UDDI praticamente morreu nos últimos anos. Por que, professor? Porque não faz mais sentido 
você manter seus serviços web em um diretório específico. Qualquer pesquisa simples no 
Google permite encontrar serviços web da organização que você deseja. Eu, por exemplo, 
simplesmente escrevi web services câmara dos deputados no Google e já encontrei uma página 
contendo os serviços web fornecidos por esse órgão. 
 
 
 
Galera, um repositório de serviços web é inútil sem alguma forma de acessá-lo. O padrão UDDI 
versão 2.0 especifica duas interfaces com diversos métodos/operações para consumidores e 
provedores de serviços interagirem. Os consumidores de serviço usam a Interface de Consulta 
(Inquiry) para localizar e consultar um serviço, e os provedores de serviço usam a Interfacede Publicação (Publisher) para publicar e atualizar um serviço. 
 
Vamos agora fazer um resumão do Paradigma SOAP! Uma aplicação (Cliente/Solicitante de 
Serviço) utiliza um serviço de diretórios (Agente de Serviço) – como o UDDI – para localizar o 
serviço web oferecido por um servidor (Servidor/Fornecedor de Serviço). O UDDI fornece várias 
informações sobre o serviço web, incluindo a sua descrição por meio do WSDL. O cliente analisa 
o WSDL e envia uma Mensagem SOAP requisitando um serviço de acordo com as especificações. 
 
A mensagem é, então, enviada para o fornecedor do serviço, que interpreta a mensagem (realiza 
o parsing da mensagem) e invoca o método apropriado, passando os parâmetros fornecidos na 
mensagem. O método executado, então, retorna o resultado para o Servidor SOAP, que escreve 
uma Mensagem SOAP respondendo a requisição inicial com o resultado e envia para o Cliente 
SOAP. Por fim, este último lê a mensagem e repassa o resultado para a aplicação requisitante. 
 
Paradigma REST 
INCIDÊNCIA EM PROVA: ALTA 
 
Antes de falarmos sobre o REST, precisamos falar um pouco sobre HTTP. O HTTP (HyperText 
Transfer Protocol) é um protocolo de comunicação utilizado para transferência de 
hipertextos. O que seria um hipertexto? Trata-se de um texto que pode ser integrado a diversas 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
17
42
outras formas de informação, como imagens, sons e outras mídias, acessíveis por meio de 
hiperlinks. Dito isso, o que importa de fato para o desenvolvimento de sistemas? 
 
Bem, esse protocolo define oito métodos de requisição (também chamados de verbos) 
responsáveis por indicar a ação a ser executada para um dado recurso. Como é, Diego? Quando 
você utiliza esse protocolo, você está basicamente fazendo uma requisição de um recurso na web 
(Ex: Página Web). No entanto, esse protocolo permite fazer bem mais do que simples requisições 
de recursos. Vamos conhecer esses oito métodos: 
 
MÉTODO DESCRIÇÃO 
GET 
Esse método solicita a representação de um recurso específico. Requisições utilizando o método 
GET devem retornar apenas dados. 
HEAD 
Esse método solicita uma resposta de forma idêntica ao método GET, porém sem conter o corpo 
da resposta. 
PUT 
Esse método substitui todas as atuais representações do recurso de destino pela carga de dados da 
requisição. 
POST 
Esse método é 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 
Esse método remove um recurso específico. 
 
TRACE 
Esse método executa um teste de chamada loop-back junto com o caminho para o recurso de 
destino. 
CONNECT 
Esse método estabelece um túnel para o servidor identificado pelo recurso de destino. 
 
OPTIONS 
Esse método é usado para descrever as opções de comunicação com o recurso de destino. 
 
PATCH 
Esse método é utilizado para aplicar modificações parciais em um recurso. 
 
 
Nosso interesse aqui está apenas nos métodos GET e POST! Notem que eu estou utilizando o 
Protocolo HTTP. Eu estou requisitando a página index.php que está hospedada no diretório 
chamado pasta do servidor cujo domínio é sitequalquer.com. Para solicitar esse recurso (página 
web), eu forneci dois parâmetros após o ponto de interrogação: nome e senha. O GET é utilizado 
para solicitar um recurso específico... 
 
http://www.sitequalquer.com/pasta/index.php?nome=Diego&senha=estrategia 
 
Já o POST é utilizado para enviar dados para um recurso, geralmente realizando alguma 
alteração. Dessa forma, GET é utilizado para leitura e POST é utilizado para criação! Ambos 
permitem o envio de parâmetros, no entanto há uma diferença fundamental entre eles: GET 
deixa os parâmetros visíveis na URL; POST esconde os parâmetros no corpo da mensagem. No 
exemplo anterior, os parâmetros estão visíveis, logo se trata de um GET. 
 
No entanto, há um risco na requisição anterior! Já notaram qual é? Como eu estou utilizando GET, 
os parâmetros estão visíveis, mas um dos parâmetros é uma senha – isso é perigosíssimo! 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
18
42
Imaginem sua senha circulando por aí entre roteadores e servidores até chegar ao destino final. 
Logo, deve-se evitar utilizar o GET quando as informações de parâmetros forem sensíveis – 
recomenda-se utiliza o POST. 
 
Lembrando que o GET é utilizado para recuperar informações (em geral, poucas) e POST é 
utilizado para enviar informações (em geral, muitas – como formulários). Agora, vamos 
examinar como as conexões seguras podem ser alcançadas. Quando a web repentinamente 
chegou ao público, ela foi utilizada apenas para páginas estáticas, mas – em pouco tempo – 
algumas empresas tiveram a ideia de usá-la para transações dinâmicas. 
 
Como assim, Diego? Uma página estática é aquela que só tem o texto com alguns links, mas que 
não possuem recursos dinâmicos que se alteram de acordo com parâmetros, login, entre outros. 
Já uma página dinâmica é como a página do Estratégia Concursos: você acessa, faz o login, vê os 
cursos em que você está matriculado, altera configurações de usabilidade, entre outros. Como 
empresas da área de finanças começaram a fazer páginas dinâmicas, surgiu uma demanda... 
 
Era necessário ter uma tecnologia para conexões mais seguras! Em 1995, a Netscape – empresa 
que dominava o mercado de navegadores web – introduziu um recurso de segurança chamado 
SSL (Secure Sockets Layer) para atender a essa demanda. O Netscape permitia, portanto, ter 
uma comunicação segura e criptografada. E a junção do SSL + HTTP resultou no HTTPS 
(atualmente, é utiliza o TLS em vez do SSL). 
 
O Protocolo SSL constrói uma conexão segura entre dois dispositivos – trata-se de uma nova 
camada colocada entre a camada de aplicação e transporte. Depois que a conexão segura é 
estabelecida, a principal tarefa da SSL é manipular a compactação e a criptografia. Galera, há 
muitos outros pontos que podem ser abordados sobre esse protocolo, mas vamos parar aqui 
porque isso tudo é só para entendermos melhor o Paradigma REST! 
 
Inicialmente, vamos falar sobre a motivação para criação do Paradigma REST! Professor, o 
Paradigma SOAP não era tudo de bom? Galera, ele realmente tinha muitas vantagens – ele 
permitia o desenvolvimento de serviços web altamente confiáveis, complexos e de 
qualidade. No entanto, como vocês devem saber, o mundo da tecnologia muda bastante de 
forma muito rápida em pouco tempo. 
 
Em 2007, começaram a se popularizar os smartphones, mas eles possuíam um baixo poder 
computacional (hoje em dia, eles são verdadeiras máquinas, mas naquela época eram bem mais 
fracos). Além disso, as redes móveis de internet ainda suportavam baixa velocidade – a 
tecnologia 3G original possuía uma velocidade máxima de download de 0.3 Mbps; o 4G atual 
suporta até 900 Mbps; e o 5G promete chegar aos 5Gbps. 
 
Em um contexto de dispositivos com baixo poder computacional e baixa velocidade de 
internet móvel, o overhead (sobrecarga) do Paradigma SOAP começou a pesar! Como assim, 
Diego? Nós vimos que uma Mensagem SOAP é composta de um Envelope com Cabeçalho, Corpo 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico deTecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
19
42
e Falhas. Além disso, ela pode conter recursos que estendem suas funcionalidades, como 
criptografia, assinatura digital, autorização, privacidade, entre outros. 
 
Vejam, portanto, que os dados em si estão no corpo da mensagem. No entanto, há diversos 
outros elementos que pesam a troca de dados. Essa foi a grande motivação para o surgimento 
de um novo paradigma mais simples e leve: Paradigma REST (REpresentational State Transfer). 
Trata-se de um estilo arquitetural ou de desenvolvimento para projetar e construir aplicações de 
rede distribuídas fracamente acopladas. Vamos conhecer as principais diferenças... 
 
 
 
Na imagem acima, temos algumas representações: o dado que deve ser transportado é 
representado por uma pessoa e o meio de transporte é o cavalo. Logo, temos que o dado 
(Pessoa) será efetivamente transportada de um ponto para outro por meio de um cavalo (HTTP). 
Além disso, temos a representação dos dois paradigmas principais: REST e SOAP. Vamos 
entender a principal diferente entre eles... 
 
No primeiro caso, se você quiser enviar um dado de um ponto para outro, você pode 
simplesmente subir no cavalo e cavalgar. No segundo caso, também temos uma pessoa e um 
cavalo, mas junto temos uma carroça. Vocês lembram que nós falamos sobre o overhead? Pois é, 
a carroça é a carga extra (sobrecarga) para transportar uma pessoa entre dois pontos. Logo, o 
segundo caso possui um peso a mais na troca de mensagens. 
 
Ambos levam uma pessoa (dado) de um Ponto A para um Ponto B por meio de um cavalo (HTTP), 
mas o primeiro é bem mais leve que o segundo. Professor, posso dizer que REST é melhor que 
SOAP? Não, tudo dependerá do contexto! Se você apenas deseja chamar um serviço leve com 
parâmetros e respostas bem diretos, utilize o REST; se você deseja passar diversos parâmetros 
compostos e aninhados com respostas complexas, utilize o SOAP. Enfim... 
 
REST é menos burocrático, tem menos overhead, suporta diversas linguagens e tem maior 
desempenho/escalabilidade. SOAP é mais burocrático, tem mais overhead, suporta apenas XML 
e tem menor desempenho/escalabilidade. Além disso, há mais uma diferença importante: no 
SOAP, existe uma especificação que deve ser seguida para todas as requisições/respostas 
(chamada WSDL); no REST, não existe nenhuma especificação obrigatória. 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
20
42
SOAP 
[SIMPLE OBJECT ACCESS PROTOCOL] 
REST 
[REPRESENTATIONAL STATE TRANSFER] 
É um protocolo de comunicação baseado em XML. 
 
É um estilo arquitetural ou de desenvolvimento 
independente de tecnologia. 
Utiliza um Envelope enviado por geralmente por 
HTTP para transmitir dados. 
Utiliza diretamente recursos oferecidos de forma 
nativa, em regra, pelo HTTP. 
Suporta somente recursos no formato XML. 
 
Suporta recursos no formato HTML XML, JSON, 
YAML, TXT, etc. 
Permite invocar serviços por meio de Métodos RPC 
(Remote Procedure Calls). 
Permite invocar serviços por meio da própria URI/URL. 
 
Em geral, apresenta desempenho e escalabilidade 
menor, devido ao alto overhead. 
Em geral, apresenta desempenho e escalabilidade 
maior, devido ao baixo overhead. 
Não permite fazer caching. 
 
Permite fazer caching. 
 
Requer maior largura de banda para trafegar os 
dados. 
Requer menor largura de banda para trafegar os 
dados. 
Suporta recursos da WS-Security para incrementar a 
segurança. 
Suporta apenas SSL/TLS e HTTPS para incrementar a 
segurança. 
JavaScript pode chamar SOAP, mas é de difícil de 
implementação. 
JavaScript pode facilmente chamar REST. 
 
 
Compreendidas essas diferenças, vamos ver agora outras características! Roy Fielding propôs 
seis restrições ou princípios que nós vamos ver em mais detalhes na tabela seguinte: 
 
RESTRIÇÃO OU 
PRINCÍPIO 
DESCRIÇÃO 
Cliente/Servidor 
Responsabilidades devem ser separadas entre clientes e servidores. Isso permite que os 
componentes do cliente e do servidor evoluam de forma independente e, por sua vez, 
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura e 
responsabilidades em dois ambientes. 
 
Dessa forma, o cliente não se preocupa com tarefas como a comunicação com banco de 
dados, gerenciamento de cache, log, entre outros; e o contrário também é válido, o servidor 
não se preocupa com tarefas como interface, experiência do usuário, entre outros. 
Permitindo, assim, a evolução independente das duas arquiteturas. 
Stateless 
(Sem Estado) 
A comunicação entre cliente e servidor deve ser stateless (isto é, sem guardar estado). O 
servidor não precisa lembrar do estado do cliente. Em vez disso, os clientes devem incluir 
todas as informações necessárias na requisição para que o servidor possa entendê-la e 
processá-la. 
 
Em outras palavras, um mesmo cliente pode mandar várias requisições para o servidor, 
porém cada uma delas deve ser independente, ou seja, toda requisição deve conter todas as 
informações necessárias para que o servidor consiga entendê-la e processá-la 
adequadamente (qualquer informação de estado deve ficar no cliente). 
Sistema em 
Camadas 
Múltiplas camadas hierárquicas, como gateways, firewalls e proxies podem existir entre o 
cliente e o servidor. As camadas podem ser adicionadas, modificadas, reordenadas, ou 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
21
42
==5617c==
removidas de forma transparente para melhorar a escalabilidade – deve ser fácil, então, 
manipular camadas (tornando o sistema mais flexível). 
 
Não é recomendado que o cliente chame diretamente o servidor sem antes passar por um 
intermediador como um Balanceador de Carga (Load Balancer). Isso garante que o cliente se 
preocupe apenas com a comunicação com o intermediador e o intermediador fique 
responsável por distribuir as requisições aos servidores da melhor maneira possível. 
Cache 
Respostas do servidor devem ser declaradas como cacheable ou noncacheable. Isso permite 
que o cliente ou seus componentes intermediários armazenem em cache respostas e 
reutilizem-nas para pedidos posteriores. Isto reduz a carga no servidor e ajuda a melhorar o 
desempenho. 
 
Isso significa que, quando um primeiro cliente solicita um determinado recurso ao servidor, 
esse processa a requisição e o cliente a armazena temporariamente em cache. Quando 
houver uma nova requisição, a resposta armazenada já está pronta para ser utilizada e nem 
precisará ser recuperada novamente. 
Interface 
Uniforme 
Todas as interações entre cliente, servidor e componentes intermediários são baseadas na 
uniformidade de suas interfaces. Isso simplifica a arquitetura geral, visto que componentes 
podem evoluir de forma independente à medida que implementem o que foi acordado em 
contrato. 
 
É basicamente um contrato para comunicação entre cliente e servidor. São regras para fazer 
um componente o mais genérico possível, tornando-o muito mais fácil de ser refatorado e 
melhorado. Obedece a quatro princípios: identificação de recursos; representação de 
recursos; respostas auto-explicativas/descritivas; e hypermídia. 
Código sob 
Demanda 
Esse princípio é opcional, na medida em que não faz parte da arquitetura em si. Ele trata da 
possibilidade de clientes poderem estender suas funcionalidades através do download e 
execução do código sob demanda. Exemplos incluemscripts Javascript, Applets Java, 
Silverlight, etc. 
 
Em outras palavras, permite que o cliente possa executar algum código sob demanda, ou 
seja, estender parte da lógica do servidor para o cliente, seja através de applets ou scripts. 
Assim, diferentes clientes podem se comportar de maneiras específicas mesmo que 
utilizando exatamente os mesmos serviços providos pelo servidor. 
 
Todas aplicações que siga essas restrições são consideradas Aplicações RESTful. Como vocês 
devem ter notado, essas restrições não ditam a tecnologia a ser utilizada para o desenvolvimento 
das aplicações. Em vez disso, a adesão a estas orientações e melhores práticas oferece a 
oportunidade de uma aplicação escalável, portátil, confiável e capaz de ter um desempenho 
melhor. Professor, aplicações RESTful são obrigadas a utilizar REST com HTTP? Não! 
 
Na teoria, elas podem utilizar qualquer protocolo para transferência dos dados; na prática, 
elas utilizam HTTP em quase 100% das vezes. Por que? Porque há muitas vantagens em utilizar 
características e recursos desse protocolo como seus métodos/verbos: GET, POST, etc. Por falar 
nisso, o que é um recurso? Também chamado de Resource, é qualquer coisa que possa ser 
acessada ou manipulada (Ex: páginas, vídeos, imagens, documentos, impressoras, etc). 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
22
42
Também é importante compreender o que é URI (Uniform Resource Identifier)! Trata-se de uma 
string (cadeia de caracteres) utilizada para identificar unicamente um recurso. Vocês já devem 
conhecer a URL (Uniform Resource Locator) – trata-se de uma URI que – além de permitir 
identificar – também indica como acessar um recurso (basta lembrar de endereços de sites). 
Recursos podem ser representados em JSON, HTML, XML, TXT, etc. 
 
Vamos ver um exemplo: há um serviço web que – dado o nome de uma pessoa – ele informa os 
três países mais prováveis da origem da pessoa. Vamos testar com o nome: Romario. 
 
https://api.nationalize.io/?name=romario 
 
 
 
O resultado está no formato JSON (que é bem mais simples que XML). Vamos formatá-lo para 
melhorar sua visualização: 
 
 
 
O resultado afirma que uma pessoa com nome Romário tem 50.0% de chance de ser do Brasil 
(BR); 15.0% de chance de ser da Holanda (NL); e 10.1% de chance de ser da Rússia (RU). Se 
testarmos com Klaus, retornará 28.9% de ser da Alemanha (DE); 27.2% de ser da Áustria (AT); e 
25% de ser da Dinamarca (DK). Se testarmos com Sato, retornará 97.2% de ser do Japão (JP); 
1.5% de ser da Turquia (TR); e 0.006% de ser da Itália (IT). 
 
Viram que eu coloquei o parâmetro na própria URL? Pois é, eu utilizei o Método GET do HTTP! 
Notem que eu não tive que acessar nenhum Repositório UDDI; eu não tive que usar nenhum 
envelope com cabeçalho, corpo, falhas, namespace, encoding, recursos adicionais de segurança 
– eu simplesmente utilizei diretamente os próprios recursos do HTTP para consumir um serviço 
web por meio do Paradigma REST. Mais simples, não? 
 
E se eu quiser mandar um monte de informações de um formulário enorme no corpo de uma 
requisição em formato JSON que atualize um banco de dados em um servidor? Também é possível 
e eu posso fazer tudo isso pela própria URL utilizando o Método POST! Para finalizar, eu gostaria 
de destacar o porquê desse estilo arquitetural se chamar REST (Representational State Transfer 
ou Transferência de Estado Representacional). 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
23
42
Basicamente isso significa que essa tecnologia permite transferir (criar, recuperar, alterar ou 
remover) o estado (também chamado de valor) de um recurso (qualquer objeto 
informacional) disponibilizado por um serviço web por meio de um formato de representação 
(Ex: JSON, XML, etc). Então, fechamos aqui a nossa aula... eu sei que se trata de um assunto 
complexo e técnico, mas vocês vão ver que os exercícios não são tão complicados. Vamos lá... 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
24
42
QUESTÕES COMENTADAS – DIVERSAS BANCAS 
 
1. (FGV / Prefeitura de Niterói-RJ – 2018) As tecnologias SOAP e REST são largamente 
utilizadas para troca de informações estruturadas em sistemas distribuídos. Sobre essas 
tecnologias, analise as afirmativas a seguir. 
 
I. REST pressupõe que cada solicitação do cliente ao servidor deve conter todas as 
informações necessárias para processar o pedido e não pode tirar proveito de qualquer 
contexto armazenado no servidor. 
 
II. As mensagens SOAP são documentos XML construídos especificamente para trafegar 
através do protocolo de transporte HTTP/HTTPS. 
 
III. REST é mais eficiente que o SOAP porque utiliza exclusivamente mensagens menores no 
formato JSON. 
 
Está correto o que se afirma em: 
 
a) I, apenas. 
b) II, apenas. 
c) III, apenas. 
d) I e II, apenas. 
e) I, II e III. 
 
Comentários: 
 
(I) Correto, visto que eles são autocontidos e steteless; (II) Errado, não é obrigatório utilizar HTTP 
/ HTTPS; (III) Errado, não é obrigatório utilizar JSON. 
 
Gabarito: Letra A 
 
2. (FGV / AL-RO – 2018) O padrão REST define um conjunto de restrições e propriedades 
baseado em HTTP. Sobre REST, analise as afirmativas a seguir. 
 
I. Web services que obedecem ao padrão REST precisam utilizar o formato JSON para 
encapsular os dados da resposta às requisições dos sistemas solicitantes. 
 
II. Os métodos GET, POST, PUT e DELETE do protocolo de comunicação HTTP são 
compatíveis com operações CRUD para a persistência de dados. 
 
III. O padrão REST pressupõe que requisições de um mesmo sistema solicitante são 
dependentes, permitindo manter o estado de cada solicitante durante várias solicitações. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
25
42
 
Está correto o que se afirma em: 
 
a) I, somente. 
b) II, somente. 
c) III, somente. 
d) I e II, somente. 
e) I, II e III. 
 
Comentários: 
 
(I) Errado, não é obrigatório utilizar JSON; (II) Correto. CRUD se refere a Create (POST), Read 
(GET), Update (PUT) e Delete (DELETE); (III) Errado, ele pressupõe que são indepedentes, não 
mantendo o estado de cada solicitante durante várias solicitações (stateless). 
 
Gabarito: Letra B 
 
3. (FGV / AL-RO – 2018) SOAP é um protocolo para troca de informações estruturadas. Sobre 
a estrutura da mensagem SOAP, analise as afirmativas a seguir. 
 
I. O formato da mensagem é baseado na linguagem de marcação XML. 
II. Os elementos Header e Body são filhos obrigatórios do elemento Envelope. 
III. O elemento Fault é opcional e quando estiver presente deve aparecer como um elemento 
filho do elemento Envelope. 
 
Está correto o que se afirma em: 
 
a) I, somente. 
b) II, somente. 
c) III, somente. 
d) I e III, somente. 
e) I, II e III. 
 
Comentários: 
 
(I) Correto; (II) Errado, Header é opcional; (III) Errado,quando estiver presente deve aparecer 
como um elemento filho do elemento Body. 
 
Gabarito: Letra A 
 
4. (FGV / BANESTES – 2018) Sobre os princípios do padrão REST, analise as afirmativas a 
seguir. 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
26
42
I. As mensagens REST são documentos texto no formato JSON. 
 
II. REST é independente do protocolo de transporte, podendo ser implementado com HTTP, 
SMTP ou JMS. 
 
III. Serviços REST são stateless, isto é, cada solicitação deve conter todas as informações 
necessárias para ser compreendida pelo servidor. 
 
Está correto o que se afirma em: 
 
a) somente I; 
b) somente II; 
c) somente III; 
d) somente I e III; 
e) I, II e III. 
 
Comentários: 
 
(I) Errado, não são necessariamente documentos no formato JSON; (II) Errado, não pode ser 
implementado com JMS; (III) Correto. 
 
Gabarito: Letra C 
 
5. (FGV / BANESTES – 2018) A linguagem baseada em XML utilizada para descrever um web 
service, suas operações e como acessá-lo é: 
 
a) XSLT 
b) XSD 
c) DTD 
d) WSDL 
e) UDDI 
 
Comentários: 
 
A linguagem baseada em XML utilizada para descrever um web service, suas operações e como 
acessá-lo é o WSDL. 
 
Gabarito: Letra D 
 
6. (FGV / BANESTES – 2018) Sobre a implementação de serviços web com padrão SOAP, 
analise as afirmativas a seguir. 
 
I. As mensagens SOAP são documentos XML. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
27
42
II. A dependência do SOAP ao protocolo de transporte HTTP é uma restrição para 
implementação deste padrão. 
III. O padrão é inadequado para troca de informações em uma plataforma descentralizada e 
distribuída. 
 
Está correto o que se afirma em: 
 
a) somente I; 
b) somente II; 
c) somente III; 
d) somente I e II; 
e) I, II e III. 
 
Comentários: 
 
(I) Correto; (II) Errado, ele não é dependente do HTTP; (III) Errado, é totalmente adequado para 
troca de informações em uma plataforma descentralizada e distribuída. 
 
Gabarito: Letra A 
 
7. (FGV / BANESTES – 2018) Usualmente, WebServices envolvem a utilização dos padrões 
XML, SOAP e WSDL. A função de cada um deles é, respectivamente: 
 
a) descrever os parâmetros, disponibilizar o serviço, transferir as mensagens; 
b) transferir as mensagens, descrever o algoritmo, transportar as mensagens; 
c) rotular e formatar os dados, transferir as mensagens, descrever a disponibilidade do 
serviço; 
d) transferir as mensagens, descrever a disponibilidade do serviço, formatar os parâmetros; 
e) descrever as classes e suas interfaces, instanciar os objetos, descrever os algoritmos. 
 
Comentários: 
 
A função de cada um deles é, respectivamente, rotular e formatar os dados, transferir as 
mensagens, descrever a disponibilidade do serviço. 
 
Gabarito: Letra C 
 
8. (CESPE / SLU-DF – 2019) Um web service pode assumir o papel de provedor de serviço e de 
consumidor de serviço. 
 
Comentários: 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
28
42
Perfeito! Um serviço web pode fazer o papel de provedor, fornecendo serviço para outra 
entidades ou de consumidor, consumindo serviço de outros serviços web. 
 
Gabarito: Correto 
 
9. (CESPE / SEFAZ-BA – 2019) Os web services são componentes de software na web que 
podem fornecer determinados serviços a aplicações criadas em diferentes linguagens. 
Podem usar o protocolo SOAP para transferência de mensagens em formato XML. Para 
descrever a estrutura destas mensagens geralmente utiliza-se: 
 
a) REST. 
b) WSDL. 
c) CORBA. 
d) RESTFUL. 
e) HTML. 
 
Comentários: 
 
O padrão utilizado para descrever a estrutura de Mensagens SOAP é o WSDL. 
 
Gabarito: Letra B 
 
10. (CESPE / BNB – 2018) SOAP utiliza um sistema de mensagens SMTP sobre a camada de 
transporte. 
 
Comentários: 
 
SOAP até pode utilizar SMTP, mas não é sobre a camada de transporte – é sobre a camada de 
aplicação. 
 
Gabarito: Errado 
 
11. (CESPE / MPE-PI – 2018) Para implementar um web service de baixo overhead que tenha 
recursos identificáveis e localizáveis por meio de uma URI (Uniform Resource Identifier) 
mediante o protocolo HTTP, pode-se utilizar o REST (Representational State Transfer). 
 
Comentários: 
 
Perfeito! Não tem nem o que acrescentar... 
 
Gabarito: Correto 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
29
42
12. (FAURGS / BANRISUL – 2018) Quais são as quatro operações para realizar tarefas definidas 
pelo serviço web no formato REST? 
 
a) CREATE, GET, PUT e UPDATE 
b) PUT, UPDATE, INSERT e DELETE 
c) POST, GET, PUT e DELETE 
d) PUT, GET, INSERT e DELETE 
e) SELECT, GET, PUT e DELETE 
 
Comentários: 
 
As quatro operações são: POST, GET, PUT e DELETE. 
 
Gabarito: Letra C 
 
13. (CESPE / STJ – 2018) Web service é uma solução utilizada na integração de sistemas e na 
comunicação entre aplicações diferentes. 
 
Comentários: 
 
Perfeito! Ele realmente permite integrar sistemas e realizar a comunicação entre aplicações. 
 
Gabarito: Correto 
 
14. (CESPE / STJ – 2018) Os serviços Web RESTful utilizam o HTTP como um meio de 
comunicação entre cliente e servidor. 
 
Comentários: 
 
Perfeito! Eles utilizam os métodos do HTTP como uma forma de realizar a comunicação entre 
um cliente e um servidor. 
 
Gabarito: Correto 
 
15. (CESPE / STJ – 2018) A REST define uma arquitetura cliente-servidor na qual o servidor não 
mantém contexto de cliente entre transações, ou seja, é stateless e toda transação contém 
as informações necessárias para satisfazer a solicitação. 
 
Comentários: 
 
Perfeito! É stateless, logo não guarda o estado da transação. 
 
Gabarito: Correto 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
30
42
==5617c==
 
16. (CESPE / STM – 2018) O SOAP é um tipo de modelo de dados XML elaborado para facilitar a 
inserção de campos HTML em páginas web. 
 
Comentários: 
 
Não tem nenhuma relação com a inserção de campos HTML em páginas web – ele é utilizado 
para a troca de mensagens entre aplicações distribuídas. 
 
Gabarito: Errado 
 
17. (CESPE / TRT-CE – 2019) Assinale a opção que apresenta o método HTTP que deve ser usado 
para a busca de recursos por meio do web service RESTful. 
 
a) delete 
b) get 
c) put 
d) options 
 
Comentários: 
 
O Método HTTP que permite buscar recursos é o GET. 
 
Gabarito: Letra B 
 
18. (IBFC / TJ-PE – 2017) Existe a necessidade em um documento XML ser identificado como 
uma mensagem SOAP. A estrutura da mensagem SOAP (Simple Object Access Protocol), em 
um documento XML,contém os seguintes elementos: 
 
a) Title (obrigatório) - Head (opcional) - Body (obrigatório) 
b) Envelope (obrigatório) - Header (opcional) - Main (obrigatório) 
c) Title (obrigatório) - Head (opcional) - Main (obrigatório) 
d) Envelope (obrigatório) - Header (opcional) - Body (obrigatório) 
e) Envelope (obrigatório) - Head (opcional) - Main (obrigatório) 
 
Comentários: 
 
SOAP contém Envelope (Obrigatório) – Header (Opcional) – Body (Obrigatório). 
 
Gabarito: Letra D 
 
19. (CCV / UFC – 2016) Sobre Web Services, assinale a opção correta. 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
31
42
a) Web services não possui suporte a mensagens com arquivos binários. 
b) WSDL é baseado em XML, enquanto SOAP é baseado em javascript. 
c) WSDL e SOAP podem ser utilizados juntos para prover Web Services. 
d) WDSL e SOAP não são recomendação do W3C (World Wide Web Consortium). 
e) Um componente Web Service desenvolvido em linguagem Java não pode ser acessado por 
meio da linguagem PHP. 
 
Comentários: 
 
(a) Errado, ele suporta sim; (b) Errado, ambos são baseados em XML; (c) Correto; (d) Errado, 
ambos são recomendados pela W3C; (e) Errado, é claro que pode. 
 
Gabarito: Letra C 
 
20. (IF-PI / IF-PI – 2016) Trata-se de um protocolo de comunicação de web services descrito por 
uma WSDL (Web Services Description Language), ele consiste de um grande arquivo XML 
trafegando entre sistemas para realizar a comunicação. O conceito se refere ao: 
 
a) SOAP. 
b) OpenLDAP. 
c) X25. 
d) DHCP. 
e) DNS. 
 
Comentários: 
 
O protocolo de comunicação descrito por um WSDL que trafega entre sistemas para realizar a 
comunicaçao é o SOAP. 
 
Gabarito: Letra A 
 
21. (FCC / AL-MS – 2016) Considere o texto abaixo: 
 
Atualmente muitos desenvolvedores têm exposto seus serviços utilizando uma abordagem que 
usa um padrão de URI, fazendo chamadas para um serviço web utilizando, por exemplo: 
http://www.empresa.com.br/programa/metodo?parâmetros=xxx Esta abordagem é adequada 
para ser utilizada em situações nas quais há limitação de recursos e de largura de banda, 
necessitando de uma estrutura de retorno em qualquer formato definido pelo desenvolvedor e 
suportada por qualquer navegador. Usa o padrão de chamadas GET, PUT, POST e DELETE e 
pode usar também objetos XMLHttpRequest que a maioria dos navegadores modernos suporta. 
 
O texto trata especificamente de 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
32
42
a) ESB. 
b) SOAP. 
c) REST. 
d) SOA. 
e) CORBA. 
 
Comentários: 
 
Quem usa o padrão de chamadas do Protocolo HTTP é o REST. 
 
Gabarito: Letra C 
 
22. (CESPE/ TCE-PA – 2016) Os web services devem ser projetados para ser utilizados 
independentemente de paradigmas de programação. 
 
Comentários: 
 
Perfeito! Eles são independentes de tecnologia... 
 
Gabarito: Correto 
 
23. (FUNIVERSA / IF-AP – 2016) SOAP (Simple Object Access Protocol) é um protocolo de 
comunicação que permite a troca de mensagens entre aplicações Web, geralmente usando 
HTTP e Webservices. Assinale a alternativa que apresenta o formato das mensagens 
utilizadas pelo SOAP. 
 
a) UDP (User Datagram Protocol) 
b) TCP (Transmission Control Protocol) 
c) XML (eXtensible Markup Language) 
d) FTP (File Transfer Protocol) 
e) ODF (Open Document Format) 
 
Comentários: 
 
O formato das mensagens utilizadas pelo SOAP é o XML. 
 
Gabarito: Letra C 
 
24. (CESPE/ TCE-PA – 2016) Para que um web service funcione corretamente, os softwares 
cliente/servidor devem ser escritos na mesma linguagem. 
 
Comentários: 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
33
42
Na verdade, independe de tecnologias – inclusindo as linguagens de programação. 
 
Gabarito: Errado 
 
25. (CESPE/ TCE-PA – 2016) Ao se usar o protocolo SOAP (Simple Object Access Protocol), cada 
solicitação e cada resposta são colocadas em um envelope SOAP, nos momentos de 
invocação e retorno de um web service, respectivamente. 
 
Comentários: 
 
Perfeito! Toda requisição e toda resposta trafega encapsulada em um Envelope SOAP. 
 
Gabarito: Correto 
 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
34
42
LISTA DE QUESTÕES – DIVERSAS BANCAS 
 
1. (FGV / Prefeitura de Niterói-RJ – 2018) As tecnologias SOAP e REST são largamente 
utilizadas para troca de informações estruturadas em sistemas distribuídos. Sobre essas 
tecnologias, analise as afirmativas a seguir. 
 
I. REST pressupõe que cada solicitação do cliente ao servidor deve conter todas as 
informações necessárias para processar o pedido e não pode tirar proveito de qualquer 
contexto armazenado no servidor. 
 
II. As mensagens SOAP são documentos XML construídos especificamente para trafegar 
através do protocolo de transporte HTTP/HTTPS. 
 
III. REST é mais eficiente que o SOAP porque utiliza exclusivamente mensagens menores no 
formato JSON. 
 
Está correto o que se afirma em: 
 
a) I, apenas. 
b) II, apenas. 
c) III, apenas. 
d) I e II, apenas. 
e) I, II e III. 
 
2. (FGV / AL-RO – 2018) O padrão REST define um conjunto de restrições e propriedades 
baseado em HTTP. Sobre REST, analise as afirmativas a seguir. 
 
I. Web services que obedecem ao padrão REST precisam utilizar o formato JSON para 
encapsular os dados da resposta às requisições dos sistemas solicitantes. 
 
II. Os métodos GET, POST, PUT e DELETE do protocolo de comunicação HTTP são 
compatíveis com operações CRUD para a persistência de dados. 
 
III. O padrão REST pressupõe que requisições de um mesmo sistema solicitante são 
dependentes, permitindo manter o estado de cada solicitante durante várias solicitações. 
 
Está correto o que se afirma em: 
 
a) I, somente. 
b) II, somente. 
c) III, somente. 
d) I e II, somente. 
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 32 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
35
42
e) I, II e III. 
 
3. (FGV / AL-RO – 2018) SOAP é um protocolo para troca de informações estruturadas. Sobre 
a estrutura da mensagem SOAP, analise as afirmativas a seguir. 
 
I. O formato da mensagem é baseado na linguagem de marcação XML. 
II. Os elementos Header e Body são filhos obrigatórios do elemento Envelope. 
III. O elemento Fault é opcional e quando estiver presente deve aparecer como um elemento 
filho do elemento Envelope. 
 
Está correto o que se afirma em: 
 
a) I, somente. 
b) II, somente. 
c) III, somente. 
d) I e III, somente. 
e) I, II e III. 
 
4. (FGV / BANESTES – 2018) Sobre os princípios do padrão REST, analise