Questão de Redes de Computadores — Protocolo — FUNDATEC 2025
Redes de Computadores›Protocolo
Código
qg475006
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Uma API baseada em Representational State Transfer (REST) do Serviço Federal de Processamento de Dados (SERPRO) adere estritamente à Request for Comments (RFC) 9110 do Hypertext Transfer Protocol (HTTP). Sobre semântica de métodos, é correto afirmar que:
APOST é idempotente por convenção de criação; PUT não é, por alterar recursos de forma variável.
BGET pode alterar estado quando o cliente é autenticado, já que a autorização implicaria intenção de mudança.
CPATCH é sempre idempotente, pois repetições não alteram o resultado.
DPUT é idempotente e GET é seguro, independentemente de autenticação.
EDELETE nunca é idempotente, porque deleções sucessivas geram respostas diferentes.
Revelar gabarito e comentário▾
GabaritoD — PUT é idempotente e GET é seguro, independentemente de autenticação.
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”.
Semântica de métodos HTTP (RFC 9110)
Gabarito: letra D. PUT é idempotente e GET é seguro, independentemente de autenticação – conforme a semântica definida na RFC 9110 (HTTP).
A questão cobra a classificação dos métodos HTTP quanto à idempotência (repetição da mesma requisição produz o mesmo efeito) e à segurança (não altera estado do servidor). As alternativas A, B, C e E invertem ou distorcem essas propriedades.
NÃO CAIA NESSA!
A banca troca os conceitos: afirma que POST é idempotente (não é) e que PUT não é (é idempotente); que PATCH é sempre idempotente (não é), que DELETE nunca é idempotente (é); que GET pode alterar estado se autenticado (nunca altera). Memorize o quadro correto dos métodos mais comuns.
Método HTTP
Seguro (não altera estado)
Idempotente (repetição = mesmo efeito)
GET
Sim
Sim
PUT
Não
Sim
DELETE
Não
Sim
POST
Não
Não
PATCH
Não
Não (inerentemente)
Métodos HTTP (RFC 9110): Seguros (não alteram estado) (GET, HEAD, OPTIONS); Idempotentes (repetição = mesmo efeito) (PUT, DELETE, GET (seguro + idempotente)); Não idempotentes (POST, PATCH (não inerentemente))
Alternativa A — ❌ Incorreta
POST não é idempotente: múltiplos POSTs criam múltiplos recursos. PUT é idempotente: a mesma requisição substitui o recurso pelo mesmo estado. Afirmação invertida.
Alternativa B — ❌ Incorreta
GET é um método seguro — não altera estado do servidor, independentemente de autenticação ou autorização. Autenticação não transforma GET em método de escrita.
Alternativa C — ❌ Incorreta
PATCH não é sempre idempotente. Embora possa ser implementado de forma idempotente, a própria RFC 9110 afirma que PATCH não é inerentemente idempotente; depende do conteúdo do patch.
Alternativa D — ✅ Correta ⟵ GABARITO
PUT é idempotente: uma mesma requisição PUT repetida mantém o estado final igual. GET é seguro: não produz efeitos colaterais, independentemente de autenticação. Afirmação correta.
Alternativa E — ❌ Incorreta
DELETE é idempotente: a primeira requisição deleta o recurso; as seguintes não têm efeito adicional (o recurso já não existe). Respostas diferentes (200 vs 404) não alteram a idempotência, que se refere ao efeito no servidor.