Pular para o conteúdo principal

Questão de Arquitetura de Software — WebServices — FCC 2026

Arquitetura de SoftwareWebServices
Código
fc077583
Banca
FCC
Órgão
SEFAZ-SP
Ano
2026
Nível
Superior
Cargo
Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)
Um órgão fazendário expõe, por meio de uma API REST, dados de notas fiscais eletrônicas para outros sistemas estaduais. Em picos de uso, algumas requisições retornam informações inconsistentes porque o processamento interno ainda está em execução de forma assíncrona. Nesse cenário, a estratégia de projeto REST adequada para garantir consistência das respostas sem bloquear o processamento da operação é
  1. Aresponder 200 OK com payload indicando processamento pendente, mantendo a consulta ao mesmo endpoint.
  2. Bexecutar todo o processamento da NF-e de forma síncrona antes de responder, garantindo resposta somente quando o dado estiver concluído.
  3. Cutilizar 206 Partial Content para devolver versões intermediárias da NF-e enquanto o processamento é concluído.
  4. Dretornar 202 Accepted para operações assíncronas e informar, no cabeçalho Location, um endpoint para consulta do status ou resultado.
  5. Eresponder com 201 Created para operações longas e orientar o cliente a aguardar nova consulta ao mesmo endpoint para obter o resultado.
Revelar gabarito e comentário

GabaritoD — retornar 202 Accepted para operações assíncronas e informar, no cabeçalho Location, um endpoint para consulta do status ou resultado.

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: Operações Assíncronas

Gabarito: letra D. No estilo REST, operações assíncronas que podem levar tempo para concluir são tratadas com o código de status HTTP 202 Accepted (não confundir com 200 OK). A resposta indica que a requisição foi aceita para processamento, mas o resultado ainda não está disponível. O cabeçalho Location fornece uma URL para o cliente consultar o status ou obter o resultado final (polling). Essa é a estratégia padrão para garantir consistência sem bloquear o cliente.

Alternativa A — ❌ Incorreta

O código 200 OK indica que a requisição foi processada com sucesso e a resposta já contém o resultado esperado. Utilizá-lo com um payload de "processamento pendente" viola o significado semântico do status e não segue as boas práticas REST.

Alternativa B — ❌ Incorreta

Executar todo o processamento de forma síncrona antes de responder resolve a consistência, mas bloqueia o cliente (a requisição fica em espera até o fim). Em uma API REST, isso pode degradar a performance e a escalabilidade, especialmente em picos de uso.

Alternativa C — ❌ Incorreta

206 Partial Content é usado para respostas parciais a requisições de intervalo (range requests), como downloads de arquivos grandes. Não se aplica a operações assíncronas em que o recurso completo ainda não está disponível.

Alternativa D — ✅ Correta ⟵ GABARITO

Retornar 202 Accepted é a prática recomendada. O servidor confirma o recebimento e inicia o processamento assíncrono. O cabeçalho Location aponta para um recurso de status onde o cliente pode verificar o progresso ou obter o resultado final (polling). Isso mantém a operação não bloqueante e garante consistência futura.

Alternativa E — ❌ Incorreta

201 Created é usado quando um novo recurso é criado com sucesso (ex.: após um POST). Não é adequado para processamento assíncrono; além disso, orientar o cliente a "aguardar nova consulta ao mesmo endpoint" sem um mecanismo claro de polling é menos robusto que o padrão com Location.

NÃO CAIA NESSA!

A banca explora a diferença entre os códigos de status HTTP. O candidato pode confundir 202 (aceito) com 200 (sucesso) ou 201 (criado). Lembre-se: operação longa e assíncrona → 202 Accepted com endpoint de consulta no cabeçalho Location.

Gabarito: letra D.

Link permanente: /questoes/fc077583