Questão de Arquitetura de Software — WebServices — Quadrix 2025
Arquitetura de Software›WebServices
Código
qg595977
Banca
Quadrix
Órgão
CRA-SP
Ano
2025
Nível
Superior
Cargo
Analista II - Desenvolvimento de Sistemas
Durante o design de uma API, uma equipe discutiu duas abordagens de integração amplamente usadas.Com base nessa situação hipotética, assinale a opção que apresenta a diferença conceitual fundamental entre as abordagens REST e SOAP.
AREST é centrado em Recursos (ex.: GET /usuario/1), enquanto SOAP é centrado em Ações (ex.: GetUsuario(id=1)).
BREST é um protocolo que exige JSON, enquanto SOAP é um estilo arquitetural que exige XML.
CREST é stateful (guarda estado no servidor), enquanto SOAP é stateless (sem estado).
DREST só funciona sobre HTTP, enquanto SOAP só funciona sobre SMTP.
EREST é mais seguro por usar JWT, enquanto SOAP é menos seguro por usar XML Signatures.
Revelar gabarito e comentário▾
GabaritoA — REST é centrado em Recursos (ex.: GET /usuario/1), enquanto SOAP é centrado em Ações (ex.: GetUsuario(id=1)).
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”.
REST × SOAP: diferenças conceituais
Gabarito: letra A. REST é um estilo arquitetural que trata recursos (substantivos) como /usuario/1 e opera sobre eles com métodos HTTP (GET, POST, PUT, DELETE); SOAP é um protocolo que expõe operações (ações) como GetUsuario(id=1) em envelopes XML, com contrato definido em WSDL. Essa é a distinção fundamental entre as abordagens.
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa captura com precisão a diferença conceitual: REST é orientado a recursos, onde cada recurso é identificado por uma URI e manipulado via métodos HTTP padronizados; SOAP é orientado a ações, onde o cliente invoca operações específicas definidas no contrato WSDL, normalmente por meio de requisições POST com payload XML. Exemplos típicos: GET /usuario/1 (REST) vs. POST /SoapService com corpo <GetUsuario><id>1</id></GetUsuario> (SOAP).
Alternativa B — ❌ Incorreta
Inverte os papéis: REST não é um protocolo, mas sim um estilo arquitetural; SOAP é um protocolo, e não um estilo arquitetural. Além disso, REST não exige JSON — pode usar XML, HTML, plain text, etc. —, enquanto SOAP exige XML como formato de mensagem (dentro de um envelope SOAP).
Alternativa C — ❌ Incorreta
Troca as características de estado. REST é stateless (cada requisição contém toda a informação necessária para o servidor processá-la, conforme princípio do estilo). SOAP não impõe stateless — embora muitas implementações também sejam stateless, o protocolo SOAP em si pode ser statefull (ex.: uso de WS-ReliableMessaging ou sessões). A afirmação está invertida.
Alternativa D — ❌ Incorreta
Afirma falsamente que REST opera apenas sobre HTTP e SOAP apenas sobre SMTP. REST, embora comumente associado ao HTTP, pode ser implementado sobre outros protocolos (HTTPS, FTP, etc.). SOAP pode ser transportado por HTTP, SMTP, JMS, TCP, entre outros. Ambos são independentes de protocolo de transporte.
Alternativa E — ❌ Incorreta
Compara segurança de forma equivocada. Não há relação intrínseca entre REST e JWT, nem entre SOAP e XML Signatures. Ambas as tecnologias de segurança podem ser usadas em ambas as abordagens. A segurança depende da implementação, não do estilo ou protocolo em si. XML Signature é uma especificação de assinatura digital para XML, usada em SOAP, mas não torna SOAP inerentemente menos seguro.
NÃO CAIA NESSA!
A banca inverte conceitos em todas as alternativas erradas. O padrão clássico é trocar "estilo arquitetural" por "protocolo" (B), "stateless" por "stateful" (C), e associar exclusividade de protocolo (D) ou segurança (E). A única que acerta a essência é a letra A: recursos vs. ações.