Questão de Arquitetura de Software — Interoperabilidade — CONSULPAM 2026
Arquitetura de Software›Interoperabilidade
Código
qg660548
Banca
CONSULPAM
Órgão
GHC-RS
Ano
2026
Nível
Médio
Cargo
Programador
Em um projeto de uma API HTTP para um sistema corporativo, um programador pretende alinhar a interface aos princípios de integração entre sistemas e ao uso adequado da semântica dos métodos e códigos de status. Nesse contexto, analise as sentenças a seguir:I- Em HTTP, o método GET é classificado como seguro e idempotente, razão pela qual seu uso é compatível com operações de recuperação de representação sem alteração intencional do estado do recurso.II- Uma resposta 201 indica que a requisição resultou na criação de um ou mais recursos, e o recurso principal criado pode ser identificado, em regra, pelo cabeçalho “location” ou, na sua ausência, pela URI efetiva da requisição.III- Em arquiteturas REST, a manutenção obrigatória de estado de sessão no servidor entre requisições é requisito estrutural para garantir consistência na interação cliente-servidor.IV- A substituição de PUT por POST preserva, por si só, a propriedade de idempotência em operações de atualização repetidas sob falha de comunicação.Analisadas as sentenças, estão CORRETAS apenas:
AI e II.
BI e III.
CI e IV.
DII e III.
EII e IV.
Revelar gabarito e comentário▾
GabaritoA — I e II.
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”.
Análise das sentenças sobre HTTP e REST
Gabarito: letra A (sentenças I e II corretas). I é verdadeira: GET é seguro e idempotente. II é verdadeira: 201 Created identifica o recurso pelo cabeçalho Location ou pela URI da requisição. III é falsa: REST exige stateless, não estado de sessão. IV é falsa: POST não é idempotente; substituir PUT por POST não preserva idempotência.
Sentença I — ✅ Correta
O método GET é classificado como seguro (não provoca alteração no estado do servidor) e idempotente (requisições repetidas produzem o mesmo resultado). Isso o torna adequado para operações de consulta/recuperação de recursos, sem efeitos colaterais. Base conceitual do HTTP.
Sentença II — ✅ Correta
O status 201 (Created) indica que a requisição resultou na criação de um ou mais recursos. O recurso principal é identificado pelo cabeçalho Location na resposta. Se esse cabeçalho não estiver presente, considera-se que o recurso foi criado na URI da própria requisição (HTTP/1.1, RFC 7231, seção 6.3.2).
Sentença III — ❌ Incorreta
Arquiteturas REST adotam o princípio de stateless (ausência de estado): cada requisição do cliente ao servidor deve conter toda a informação necessária para ser compreendida, não havendo armazenamento de contexto de sessão no servidor entre requisições. A afirmação de que "a manutenção obrigatória de estado de sessão no servidor é requisito estrutural" contraria a restrição fundamental do estilo REST. Embora a consistência seja desejável, REST não impõe estado no servidor; a responsabilidade pela sessão é do cliente.
Sentença IV — ❌ Incorreta
O método PUT é idempotente por definição: uma requisição PUT repetida com a mesma representação produz o mesmo estado no servidor. O método POST, por sua vez, não é idempotente; múltiplas requisições POST podem criar múltiplos recursos (ou efeitos colaterais). Portanto, substituir PUT por POST não preserva a idempotência — pelo contrário, a perde.
Sentença
Afirmação
Status
Justificativa
I
GET é seguro e idempotente, compatível com recuperação de recursos
✅ Correta
GET não altera estado do servidor (seguro) e requisições repetidas produzem mesmo resultado (idempotente)
II
201 Created identifica recurso pelo cabeçalho Location ou pela URI da requisição
✅ Correta
Conforme RFC 7231, seção 6.3.2, o recurso principal é identificado pelo Location; na ausência, pela URI da requisição
III
REST exige manutenção obrigatória de estado de sessão no servidor
❌ Incorreta
REST adota stateless: cada requisição deve conter toda informação necessária, sem armazenamento de sessão no servidor
IV
Substituir PUT por POST preserva idempotência
❌ Incorreta
PUT é idempotente; POST não é — múltiplas requisições POST podem criar múltiplos recursos
NÃO CAIA NESSA!
A banca explora duas confusões clássicas: (1) achar que REST mantém estado de sessão no servidor (quando o correto é stateless); (2) achar que POST é idempotente como PUT. Memorize: GET, PUT e DELETE são idempotentes; POST não é. REST é stateless.
Gabarito: letra A — apenas as sentenças I e II estão corretas.