Questão de TI - Desenvolvimento de Sistemas — Geral — VUNESP 2026

REST: métodos HTTP e códigos de status

Gabarito: letra B. A requisição POST /produtos com corpo JSON é uma operação de criação de recurso; quando processada com sucesso, a convenção REST determina a resposta com o código de status 201 Created (RFC 9110). As demais alternativas confundem o método POST com GET, PUT/PATCH ou apresentam leituras incorretas do corpo JSON.

O que está em jogo aqui é o mapeamento entre os métodos HTTP e os códigos de status em uma API REST. O método POST é usado para criar um novo recurso no servidor. Quando a criação é bem-sucedida, o servidor deve responder com 201 Created, indicando que o recurso foi criado e, geralmente, incluindo no corpo da resposta uma representação do novo recurso (com o Location header apontando para a URI do recurso criado). Esse é um dos códigos de status mais característicos de APIs REST e cai com frequência em provas.

Vamos entender cada código mencionado nas alternativas:

• 200 OK: resposta genérica de sucesso, usada quando a requisição foi processada com sucesso e o corpo da resposta contém o resultado. É o código padrão para GET, PUT e DELETE bem-sucedidos.

• 201 Created: resposta específica para operações de criação (POST ou PUT com criação). Indica que um novo recurso foi criado no servidor.

• 404 Not Found: indica que o recurso solicitado não existe no servidor. É típico de GET/PUT/DELETE quando a URI não corresponde a nenhum recurso.

• 400 Bad Request: indica que a requisição está malformada — por exemplo, JSON inválido, campos obrigatórios ausentes, ou tipos de dados incorretos.

A pegadinha desta questão está em confundir o método POST com GET ou com operações de atualização. O candidato que lê rapidamente pode achar que a requisição busca um produto (GET) ou altera parcialmente um recurso (PATCH), mas o verbo POST + o caminho /produtos (sem identificador) deixa claro que se trata de criação de um novo produto.

Outro ponto que merece atenção: o corpo JSON apresentado não tem erro de sintaxe. Embora as chaves não estejam entre aspas duplas (o que é obrigatório no JSON padrão), a banca considerou o JSON válido — provavelmente por se tratar de uma representação simplificada. Na prática, um JSON com chaves sem aspas é inválido, mas a alternativa C afirma que há erro de sintaxe e que isso geraria 400 Bad Request; como a banca não considerou esse erro, a alternativa C está incorreta. Se o JSON fosse realmente inválido, a resposta seria 400, mas a questão não adota essa leitura.

Guarde a relação entre método e código de status: POST → 201 Created é a assinatura clássica de criação em REST. É nessa relação que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A alternativa afirma que, se o recurso não for encontrado, espera-se 404 Not Found. Isso seria verdade se a requisição fosse um GET /produtos/XYZ123 (busca de um recurso específico). Mas aqui temos um POST /produtos, que cria um novo recurso — não busca um existente. O 404 não se aplica a uma operação de criação; se o servidor não encontrar algo, seria mais provável um 409 Conflict (se o produto já existir) ou 422 Unprocessable Entity (se houver erro de validação). O 404 é típico de GET, PUT ou DELETE quando a URI não existe.

Alternativa B — ✅ Correta ⟵ GABARITO

A requisição é um POST para /produtos, com corpo JSON contendo os dados do produto. Em REST, POST é o método para criar um novo recurso. Quando a criação é bem-sucedida, o código de status padrão é 201 Created (RFC 9110, seção 15.3.3). A alternativa B espelha exatamente essa convenção: "Se a requisição for processada com sucesso, espera-se uma resposta com código de status 201 Created." É a resposta correta.

Alternativa C — ❌ Incorreta

A alternativa afirma que o corpo JSON tem erro de sintaxe e que isso geraria 400 Bad Request. De fato, um JSON com chaves sem aspas duplas é tecnicamente inválido (a especificação JSON exige aspas duplas nas chaves). No entanto, a banca não considerou esse erro — o corpo foi tratado como válido para fins da questão. Além disso, mesmo que houvesse erro de sintaxe, o código seria 400 Bad Request, mas a alternativa C está incorreta porque a premissa do erro de sintaxe não foi adotada pela banca. Se você marcar C, estará caindo na pegadinha de "achar" um erro onde a questão não vê.

Alternativa D — ❌ Incorreta

A alternativa descreve uma resposta que seria típica de um GET com parâmetros de busca (query string ou filtros), retornando um array de produtos que atendam aos critérios. Mas a requisição é um POST de criação — não uma busca. O POST /produtos cria um único produto; a resposta esperada é o recurso criado (ou apenas o status 201), não uma lista de produtos. A alternativa confunde o método POST com GET e o conceito de criação com o de consulta.

Alternativa E — ❌ Incorreta

A alternativa afirma que a requisição propõe a alteração parcial de um recurso existente. Isso seria o papel do método PATCH (alteração parcial) ou PUT (alteração total). O POST, por definição, é para criar um novo recurso — não para alterar um existente. Além disso, a URI /produtos não contém um identificador (como /produtos/XYZ123), o que reforça que se trata de criação, não de atualização de um recurso específico. A alternativa E troca o método POST por PATCH/PUT.

Gabarito: letra B