Em um ambiente tão heterogêneo como a Internet, elementos de interoperabilidade são fundamentais, e os Web Services são o modelo mais comum para o fornecimento de serviços independentes de plataforma.Uma característica das tecnologias de Web Services é:
Aa criação automática de um cliente Java para Web Services do tipo SOAP é possível em diversas IDEs com o simples fornecimento do endereço do descritor de serviços, que segue a sintaxe OMG-IDL;
Bo protocolo SOAP garante a transparência para firewalls e independência de plataforma através do uso de comunicação em modo texto no formato JSON;
Cao lidar com um Web Service do tipo RESTful, as operações relacionadas à alteração de dados, de acordo com o padrão estabelecido, devem ser efetuadas via método POST;
Dsegundo o padrão da arquitetura REST, a obtenção de todas as entidades a partir de um Web Service do tipo RESTful ocorrerá com o acesso ao endereço de base do serviço via método GET do protocolo HTTP;
Epor não serem capazes de manter estado, as tecnologias de Web Services não permitem acesso autenticado, trazendo fragilidade em termos de segurança.
Revelar gabarito e comentário▾
GabaritoD — segundo o padrão da arquitetura REST, a obtenção de todas as entidades a partir de um Web Service do tipo RESTful ocorrerá com o acesso ao endereço de base do serviço via método GET do protocolo HTTP;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Web Services: REST e SOAP
Gabarito: letra D. A alternativa D está correta porque, na arquitetura REST, a obtenção de todos os recursos de uma coleção é feita com uma requisição GET ao endpoint base do serviço (ex: GET /usuarios). Esse é o padrão RESTful para operações de leitura.
A questão aborda conceitos fundamentais de Web Services, especialmente as diferenças entre SOAP e REST. Vamos analisar cada alternativa:
Característica
SOAP
REST
Formato de mensagem
XML
JSON, XML, etc.
Descritor de serviço
WSDL (XML)
Não obrigatório (documentação)
Método para criação de recurso
Operação definida no WSDL
POST
Método para alteração de recurso
Operação definida no WSDL
PUT ou PATCH
Método para leitura de coleção
Operação definida no WSDL
GET
Estado da sessão
Pode manter estado (stateless opcional)
Stateless (obrigatório)
Autenticação
Possível (WS-Security, etc.)
Possível (JWT, OAuth, etc.)
Web Services
1SOAP
Formato: XML
Descritor: WSDL
Transporte: HTTP (pode ser bloqueado)
2RESTful
GET: obter recurso(s)
POST: criar
PUT/PATCH: alterar
DELETE: remover
Stateless
Autenticação via token (JWT/OAuth)
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que o descritor de serviços SOAP segue a sintaxe OMG-IDL. Isso é falso: o descritor de serviços SOAP é o WSDL (Web Services Description Language), baseado em XML, enquanto OMG-IDL é uma linguagem de descrição de interfaces usada pela CORBA, não por Web Services.
Alternativa B — ❌ Incorreta
Diz que o SOAP usa JSON como formato de comunicação. Na verdade, o SOAP utiliza XML para a estrutura das mensagens. Embora possa usar HTTP como transporte, não é correto afirmar que garante transparência para firewalls; firewalls podem bloquear tráfego SOAP. A independência de plataforma vem do XML, não do "modo texto" especificamente.
Alternativa C — ❌ Incorreta
Afirma que alterações de dados em RESTful devem ser feitas via POST. No REST, o método POST é usado para criação de novos recursos. A alteração (atualização) é feita via PUT (substituição completa) ou PATCH (atualização parcial). Portanto, a alternativa troca o método correto.
Alternativa D — ✅ Correta ⟵ GABARITO
Descreve corretamente o padrão REST: a obtenção de todas as entidades (coleção de recursos) é feita com o método GET no endereço de base do serviço. Por exemplo, GET /clientes retorna a lista de todos os clientes. É o princípio fundamental do REST.
Alternativa E — ❌ Incorreta
Afirma que Web Services não permitem acesso autenticado por não manterem estado (stateless). Isso é falso: mesmo serviços RESTful, que são stateless por design, podem utilizar autenticação baseada em token (JWT, OAuth) enviado em cada requisição. A ausência de estado não impede a autenticação.
NÃO CAIA NESSA!
A banca mistura conceitos de SOAP e REST, troca formatos (XML vs JSON), métodos HTTP (POST vs PUT/PATCH) e nega a possibilidade de autenticação. Fique atento às definições padrão: WSDL para SOAP, XML como formato, GET para leitura, PUT/PATCH para atualização, e autenticação via tokens em REST.