Questão de Arquitetura de Software — Interoperabilidade — CESPE / CEBRASPE 2025
Arquitetura de Software›Interoperabilidade
Código
ce202042
Banca
CESPE / CEBRASPE
Órgão
EMBRAPA
Ano
2025
Nível
Superior
Cargo
Pesquisador – Área: Gestão da Informação – Subárea: Engenharia de Dados
Considerando os métodos HTTP utilizados em APIs REST, julgue o próximo item, a respeito de integração de dados e mecanismos de interoperabilidade.O método POST é seguro e idempotente, pois a execução de múltiplas requisições resulta no mesmo estado final dos dados.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Métodos HTTP em APIs REST: segurança e idempotência
Gabarito: ERRADO (E). A afirmação de que o método POST é seguro e idempotente está incorreta. Na arquitetura REST, POST não é seguro (altera o estado do servidor) e não é idempotente (requisições repetidas criam múltiplos recursos ou efeitos diferentes). Apenas os métodos GET, HEAD, OPTIONS e TRACE são considerados seguros; entre os seguros, GET, HEAD, PUT e DELETE são idempotentes, mas POST e PATCH não o são.
A banca testa o conhecimento das propriedades dos métodos HTTP. A confusão comum é achar que POST é idempotente por ter corpo ou por ser usado em criações, mas o padrão RFC 7231 define claramente:
RFC 7231, Seção 4.2.2:
"A request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request."
"A request method is considered safe if the defined semantics are essentially read-only."
O POST, por definição, não é seguro (causa alterações) e não é idempotente (cada requisição pode criar um novo recurso ou gerar efeitos diferentes). O exemplo clássico: enviar duas vezes um POST de criação de pedido gera dois pedidos distintos, não o mesmo estado final.
❌ ERRADO
O item afirma que POST é seguro e idempotente. A afirmativa é falsa porque:
POST não é seguro: modifica dados no servidor (cria, atualiza ou dispara ações).
POST não é idempotente: requisições repetidas não garantem o mesmo estado final – cada uma pode gerar um recurso novo (ex.: dois cadastros do mesmo usuário).
NÃO CAIA NESSA!
A banca inverte as propriedades: seguridade e idempotência são atributos dos métodos GET e PUT, não do POST. Cuidado para não confundir: POST é usado para criar, mas isso justamente o torna não seguro e não idempotente.