O que é um código de status de resposta adequado para o POST quando o recurso pai não é encontrado?

Eu tenho o seguinte ponto de extremidade:

a/{id}/b

e deseja criar uma solicitação de benvio POSTpara ele. Se acom dado {id}não for encontrado, devo responder com 404 NOT_FOUNDou talvez com 409 CONFLICT?

É simples a/{id}, o truque é que aqui é usado um sub-recurso.

— Opala
fonte

Possível duplicata de Como lidar com regras de negócios com uma API REST?

— mosquito

Respostas:

404 NOT FOUNDparece a resposta apropriada, porque o recurso com esse ID não existe. É muito claro para entender e você espera a mesma resposta se a/{id}for chamado.

409 CONFLICTnão me parece a melhor escolha, porque no seu exemplo você retornará um 409 quando o recurso pai não foi encontrado :).

Mas lembra que o mais importante é ser consistente na sua API

— Dherik
fonte

Concordo. Se você tentar gravar em uma pasta que não existe, é um conflito ou um erro de pasta ausente? Parece mais intuitivo para mim.

— Neil

Uma "pasta" você quer dizer um caminho que não existe?

— Dherik

Quero dizer uma pasta, como no sistema de arquivos.

— Neil

Você pode detalhar o cenário? Porque depende. Se a pasta era esperada para o servidor e (por qualquer motivo) não estiver lá, acho que isso é um erro do servidor (5xx) e não um erro do cliente (4xx). Se esse valor da pasta foi passado pelo cliente para o recurso (como o id), é 404. Mas se a pasta foi passada no corpo, isso poderia ser outra coisa (412, 422 ... algo para representar "a validação falhou: a pasta não não existe"). É uma boa pergunta para perguntar e discutir.

— Dherik

Se você solicitar ao servidor um arquivo com o caminho /nonexistent/help.html e a pasta / inexistente não existir, haverá apenas uma resposta clara para isso. Arquivo 404 não encontrado! Pode até existir um /home/help.html, e a resposta não será diferente. Esta é uma aplicação REST claramente, mas não vejo razão para a lógica mudar. O pai deve existir primeiro.

— Neil

Além da resposta de @ Dherik.

URIs são identificadores , portanto, devemos ter em mente que ( /a/{id}/bé um identificador). O URI não faz sentido para a WWW, assim como para o cliente HTTP.

404 é a resposta certa . Em essência, o servidor está respondendo

Não encontrei nenhum recurso com esse ID. Recurso não encontrado ¹

Se o recurso ausente é pai ou filho , não importa.

Nós, desenvolvedores, vemos hierarquias e caminhos no URI, mas os clientes HTTP não. Em outras palavras, o HTTP deve ser interpretado apenas por clientes HTTP, mas não por humanos (desenvolvedores, usuários finais, etc.).

Em caso de dúvida, não pergunte que código faz sentido para você (humano). Pergunte, qual código faz sentido para o cliente HTTP. Como você deseja que o cliente HTTP se comporte?

Por quê? Porque algum código de status faz com que esses clientes executem determinadas operações. Por exemplo, 302 . Esse código geralmente faz com que os navegadores da web redirecionem para um local específico (URI) informado nos cabeçalhos de resposta.

Pode não ser o seu caso, mas é importante estar ciente. Por fim, os códigos de status HTTP são endereçados aos clientes HTTP. Não para nossas aplicações. Não para pessoas.

^{1: 409 raramente é implementado como erro de navegação. Geralmente envolve a execução de operações remotas (excluir, atualizar, novo, etc). Mas o URI deve existir. Caso contrário, 404 prevalecerá}

— Laiv
fonte