4
respostas

[Bug] Luri com bug na interpretação da resposta

A Luri não aceitou de jeito algum as minhas respostas mesmo estando corretas e mesmo eu comentando sobre o "erro 404".

Então ela perguntou se eu queria a questão como múltipla escolha e eu aceitei.

Conclusão, nas alternativas a resposta correta era algo que eu já tinha mencionado. Inclusive no comentário da resposta que a Luri fez eu já havia respondido a mesma coisa do comentário.

Insira aqui a descrição dessa imagem para ajudar na acessibilidade

Isso sugere que a correção automática da Luri está excessivamente rígida, esperando umo texto específico em vez de avaliar o conteúdo da resposta.
.

EXEMPLO:

Minha última resposta foi:
A requisição vai retornar erro 404, porque o método está mapeado para o caminho /produtos/id, e não para um valor dinâmico. O correto seria usar @DeleteMapping("/{id}") para indicar um parâmetro dinâmico.

.

Resposta da Luri:
Pablo, tente responder novamente. Sua análise sobre a necessidade de configurar a captura de valores dinâmicos com @PathVariable está correta, mas o problema não está relacionado à conversão do tipo do parâmetro. Releia o enunciado com atenção e verifique se o endpoint está configurado corretamente para receber o parâmetro. Pense no que acontece quando o Spring Boot não consegue encontrar um recurso correspondente à requisição.

4 respostas

Oi, Pablo! Tudo certo?

A questão está no mapeamento do endpoint. O método está anotado com @DeleteMapping("/id"), o que significa que o Spring Boot espera uma URL exatamente igual a /produtos/id, em vez de um valor dinâmico. Para que o Spring reconheça o parâmetro como dinâmico, você precisa usar @DeleteMapping("/{id}").

A sua análise sobre o erro 404 está correta, pois a URL /produtos/0 não corresponde ao mapeamento esperado, resultando em um recurso não encontrado.

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Comigo aconteceu a mesma coisa! Coloquei esse erro de todas as formas e nada dela aceitar

Oi Renata! Tudo bem?

Se ainda não conseguiu resolver esse problema, peço que abra um novo tópico dando mais informações sobre o seu projeto ou até mesmo compartilhando ele por completo.

Oi Renata, bom dia!
A resposta indicada como correta está incorreta, e a justificativa que a acompanha também está equivocada, pois ela contradiz o próprio código que foi apresentado na questão.

Vamos analisar o porquê.

  1. Análise do Código
    O código que você mostrou é:
    @DeleteMapping("/{id}")
    public void apagar(@PathVariable Long id) {
    repository.deleteById(id);
    }

A resposta indicada como correta está incorreta, e a justificativa que a acompanha também está equivocada, pois ela contradiz o próprio código que foi apresentado na questão.

Vamos analisar o porquê.

  1. Análise do Código
    O código que você mostrou é:

Java

@DeleteMapping("/{id}")
public void apagar(@PathVariable Long id) {
repository.deleteById(id);
}
A anotação @DeleteMapping está correta. O parâmetro dinâmico id está corretamente envolto em chaves ({}).

A justificativa que diz que "faltou o {}" está errada, pois o código já possui as chaves.

  1. Análise do Comportamento da Aplicação
    A sua aplicação Spring tem o seguinte comportamento:

A classe Controller está mapeada para /produtos.

O método apagar está mapeado para /{id}.

A URL completa para o método é DELETE /produtos/{id}.

Quando você faz uma requisição para DELETE /produtos/0, o Spring encontra o método apagar, e a variável id recebe o valor 0.

Nesse momento, o método repository.deleteById(0) é chamado.

  1. O que deleteById(0) faz
    A maioria dos bancos de dados, por padrão, utiliza IDs (chaves primárias) que começam do 1. É extremamente raro que um ID tenha o valor 0.

A implementação padrão de deleteById do Spring Data JPA não lança uma exceção EntityNotFoundException se o ID não for encontrado. Ela simplesmente executa a operação, que resulta em nenhuma linha sendo deletada, e o método void retorna normalmente.

Como nenhuma exceção é lançada, o Spring não tem motivo para retornar um erro 404 Not Found. Na verdade, o servidor provavelmente responderá com um status 200 OK ou 204 No Content (que é o padrão para operações de deleção bem-sucedidas), pois a requisição foi processada sem problemas do lado do servidor.

Conclusão
A resposta correta é que nenhuma das opções A, B ou C descreve o comportamento com precisão.

A resposta A está errada, pois a operação deleteById já é transacional por padrão.

A resposta B está parcialmente certa na premissa (o ID 0 causa um problema lógico), mas está errada ao dizer que "ocorrerá um erro" no sentido de uma exceção. O método não lança um erro, ele apenas não deleta nada.

A resposta C está totalmente errada, pois a justificativa é falsa e o método não retornará um erro 404 Not Found.

A sua aplicação não apresentará nenhum erro. A requisição será processada, mas o produto com ID 0 simplesmente não será encontrado e, portanto, não será apagado.