Questão de Arquitetura de Software — Arquitetura de Software — FUNCERN 2025
Arquitetura de Software›Arquitetura de Software
Código
qg465610
Banca
FUNCERN
Órgão
IF-PE
Ano
2025
Nível
Superior
Cargo
Analista de Tecnologia da Informação - Área Desenvolvimento
Uma API REST foi projetada para operações críticas de alta concorrência. Durante testes, percebe-se que múltiplas requisições PUT concorrentes estão sobrescrevendo dados indevidamente. Com o intuito de mitigar este problema, considerando que o método HTTP usado será o mesmo, a técnica mais adequada será
Ausar o método PATCH em vez de PUT, assumindo que atualizações parciais evitam condições de corrida.
Bativar HTTP/2 para a API, confiando que o protocolo resolverá automaticamente conflitos de escrita concorrente.
Cadicionar um cabeçalho Idempotency-Key nas requisições, garantindo que requisições repetidas não resultem em múltiplas atualizações.
Dusar exclusivamente autenticação básica (Basic Auth), presumindo que a identificação do usuário impedirá sobrescritas indevidas.
Eimplementar controle de versão de recursos com ETags e cabeçalhos If-Match, rejeitando atualizações quando a versão enviada pelo cliente não corresponder à versão atual do recurso.
Revelar gabarito e comentário▾
GabaritoE — implementar controle de versão de recursos com ETags e cabeçalhos If-Match, rejeitando atualizações quando a versão enviada pelo cliente não corresponder à versão atual do recurso.
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”.
Controle de Concorrência em API REST
Gabarito: letra E. A técnica mais adequada para evitar sobrescritas indevidas em operações PUT concorrentes é o controle de versão de recursos com ETags e cabeçalho If-Match. Essa abordagem implementa locking otimista: o cliente envia o ETag da versão que leu no cabeçalho If-Match; se o recurso foi alterado por outra requisição, o servidor responde com 412 Precondition Failed, rejeitando a atualização. Nenhuma outra alternativa resolve o problema de concorrência.
O problema central é a condição de corrida (race condition) em escritas simultâneas. A banca testa o conhecimento de mecanismos HTTP para concorrência, em contraste com técnicas de idempotência ou segurança.
1Cliente lê recurso (GET)
2Servidor retorna ETag (versão)
3Cliente envia PUT com If-Match: ETag
4Servidor compara ETags
5Iguais → [+] Atualiza (200 OK)
6Diferentes → [-] 412 Precondition Failed
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Usar PATCH em vez de PUT não elimina condições de corrida. O método PATCH é para atualizações parciais, mas ambas as requisições concorrentes podem chegar juntas e sobrescrever dados. A solução exige controle de versão, não mudança de método.
Alternativa B — ❌ Incorreta
HTTP/2 é um protocolo de transporte que melhora performance (multiplexação, compressão), mas não resolve conflitos de escrita no nível da aplicação. O conflito persiste independentemente da versão do HTTP.
Alternativa C — ❌ Incorreta
Idempotency-Key garante que requisições repetidas (mesma chave) não criem múltiplos efeitos – útil para idempotência de POST ou PATCH. Porém, o problema são requisições diferentes e concorrentes ao mesmo recurso. A chave de idempotência não evita que duas atualizações distintas se sobrescrevam.
Alternativa D — ❌ Incorreta
Autenticação (Basic Auth) apenas identifica o cliente; não impede concorrência. Dois usuários autenticados podem enviar PUT simultaneamente e sobrescrever dados.
Alternativa E — ✅ Correta ⟵ GABARITO
ETag (Entity Tag) é um identificador de versão do recurso. O cabeçalho If-Match permite que o servidor verifique se a versão enviada pelo cliente é a atual. Se não for, rejeita a requisição com 412 Precondition Failed, e o cliente deve reobter o recurso antes de tentar atualizar novamente. Essa é a técnica padrão de locking otimista para APIs REST.