Digamos que você queira obter a lista de usuários chamando GETpara api/users, mas atualmente a tabela foi truncada de forma que não há usuários. Qual é a resposta adequada para este cenário: 404ou 204?
Eu responderia com 200 e uma coleção vazia (não um corpo de resposta vazio, mas uma coleção sem elementos dentro, isso vai parecer diferente dependendo do formato retornado)
toniedzwiedz
4
404 neste contexto provavelmente seria mais adequado para 'tabela não encontrada'. Eu diria para retornar uma lista vazia.
@EJoshuaS Não é. Ambas as perguntas são minhas e muito antigas. Eles são semelhantes, mas não duplicados.
IMB
1
@EJoshuaS Obviamente, não são duplicatas. Esta questão é sobre /api/usersenquanto aquela outra é sobre /api/users/1.
Franklin Yu
Respostas:
231
Eu diria, nenhum.
Por que não 404 (não encontrado)?
O código de status 404 deve ser reservado para situações em que um recurso não seja encontrado. Nesse caso, seu recurso é uma coleção de usuários . Esta coleção existe, mas está vazia no momento. Pessoalmente, ficaria muito confuso como autor de um cliente para seu aplicativo se recebesse um 200um dia e um 404no dia seguinte só porque alguém removeu alguns usuários. O que eu deveria fazer? Meu URL está errado? Alguém mudou a API e se esqueceu de deixar um redirecionamento.
O servidor atendeu à solicitação, mas não precisa retornar um corpo de entidade e pode desejar retornar metainformações atualizadas.
Embora isso possa parecer razoável neste caso, acho que também confundiria os clientes. Um 204deve indicar que alguma operação foi executada com sucesso e nenhum dado precisa ser retornado. Isso é perfeito como uma resposta a uma DELETEsolicitação ou talvez para disparar algum script que não precise retornar dados. No caso de api/users, você geralmente espera receber uma representação de sua coleção de usuários. Enviar um corpo de resposta uma vez e não enviá-lo da outra é inconsistente e potencialmente enganoso.
Por que eu usaria um 200 (OK)
Por razões mencionadas acima (consistência), eu retornaria uma representação de uma coleção vazia. Vamos supor que você esteja usando XML. Um corpo de resposta normal para uma coleção não vazia de usuários pode ser assim:
e se a lista estiver vazia, você pode apenas responder com algo assim (enquanto ainda usa um 200):
<users/>
De qualquer forma, um cliente recebe um corpo de resposta que segue um formato certo e conhecido. Não há confusão desnecessária e verificação de código de status. Além disso, nenhuma definição de código de status é violada. Todo mundo está feliz.
Você pode fazer o mesmo com JSON ou HTML ou qualquer formato que esteja usando.
Definitivamente concordo. E para REST, eu simplesmente enviar de volta um código de status 200 com um array vazio: [].
Chad Johnson de
Faz sentido. Não há necessidade de tornar isso mais difícil. 404 seria confuso.
Witold Kaczurba de
Vamos supor API que descreve moedas em seu bolso, com pontos finais: GET /singleCoin- retorna uma única moeda aleatória de seu bolso, GET /severalCoins- retorna algumas moedas de seu bolso que você pode pegar de uma vez. Digamos que você não tenha moedas no bolso agora. Quando você pedir, GET /singleCoinvocê receberá 404 Not Found, mas quando você pedir, GET /severalCoinsreceberá 200 OKcom a lista vazia []. Um fato - você não tem moedas, descrito com respostas diferentes, por quê? Eu diria que é melhor sempre pegar 404 Not Found, porque não há moedas no seu bolso.
sempasha
1
@sempasha Depende do que você entende por GET /severalCoins. Se você determinar que GET /severalCoinsdeve devolver algumas moedas, então não deve ser 200 porque não está OK; o servidor falhou em fornecer o que o cliente deseja. Pois /singleCoinisso é óbvio porque o cliente quer exatamente uma moeda, nem mais, nem menos. É o mesmo para /coins/7. Em contraste com o /coinsterminal, normalmente os clientes não esperam nenhuma moeda, uma moeda ou várias moedas. Todos eles são respostas válidas. Se não houver moeda, é isso que eles querem. É como um emply List<Coin>em Java, em vez de null.
Franklin Yu
15
Eu responderia um de dois códigos, dependendo da situação do tempo de execução:
404 não encontrado)
Esta resposta é bastante correta se você não tiver mesa. Não apenas a mesa vazia, mas NENHUMA TABELA DE USUÁRIO. Ele confirma a ideia exata - nenhum recurso. Outras opções são fornecer mais detalhes PORQUE sua tabela está ausente, há alguns códigos mais detalhados, mas 404 é muito bom para se referir a situações em que você realmente não tem uma mesa.
200 (OK)
Todos os casos em que você tem tabela, mas ela está vazia ou seu processador de solicitação filtrou todos os resultados. Isso significa que 'sua solicitação está correta, tudo está OK, mas você não corresponde a nenhum dado apenas porque não temos dados ou não temos dados que correspondam à sua solicitação. Isso deve ser diferente da resposta de negação de segurança. Eu também voto para retornar 200 na situação em que você tem alguns dados e, em geral, você tem permissão para acessar a tabela, mas não tem acesso a todos os dados que correspondem à sua solicitação (os dados foram filtrados por causa da segurança no nível do objeto, mas em geral você tem permissão para solicitação).
Se você está esperando uma lista de objetos de usuário, a melhor solução é retornar uma lista vazia ([]) com 200 OK do que usar uma resposta 404 ou 204.
404 significa recurso não encontrado. Mas o recurso existe. E também, se a resposta tiver status 404. Como você pode saber a lista de usuários vazia ou preenchida?
'/ users' se estiver vazio deve retornar '200'.
'/ users / 1' se o id não for encontrado. deve retornar 404.
/api/usersenquanto aquela outra é sobre/api/users/1.Respostas:
Eu diria, nenhum.
Por que não 404 (não encontrado)?
O código de status 404 deve ser reservado para situações em que um recurso não seja encontrado. Nesse caso, seu recurso é uma coleção de usuários . Esta coleção existe, mas está vazia no momento. Pessoalmente, ficaria muito confuso como autor de um cliente para seu aplicativo se recebesse um
200um dia e um404no dia seguinte só porque alguém removeu alguns usuários. O que eu deveria fazer? Meu URL está errado? Alguém mudou a API e se esqueceu de deixar um redirecionamento.Por que não 204 (sem conteúdo)?
Aqui está um trecho da descrição do código de status 204 por w3c
Embora isso possa parecer razoável neste caso, acho que também confundiria os clientes. Um
204deve indicar que alguma operação foi executada com sucesso e nenhum dado precisa ser retornado. Isso é perfeito como uma resposta a umaDELETEsolicitação ou talvez para disparar algum script que não precise retornar dados. No caso deapi/users, você geralmente espera receber uma representação de sua coleção de usuários. Enviar um corpo de resposta uma vez e não enviá-lo da outra é inconsistente e potencialmente enganoso.Por que eu usaria um 200 (OK)
Por razões mencionadas acima (consistência), eu retornaria uma representação de uma coleção vazia. Vamos supor que você esteja usando XML. Um corpo de resposta normal para uma coleção não vazia de usuários pode ser assim:
e se a lista estiver vazia, você pode apenas responder com algo assim (enquanto ainda usa um
200):De qualquer forma, um cliente recebe um corpo de resposta que segue um formato certo e conhecido. Não há confusão desnecessária e verificação de código de status. Além disso, nenhuma definição de código de status é violada. Todo mundo está feliz.
Você pode fazer o mesmo com JSON ou HTML ou qualquer formato que esteja usando.
fonte
[].GET /singleCoin- retorna uma única moeda aleatória de seu bolso,GET /severalCoins- retorna algumas moedas de seu bolso que você pode pegar de uma vez. Digamos que você não tenha moedas no bolso agora. Quando você pedir,GET /singleCoinvocê receberá404 Not Found, mas quando você pedir,GET /severalCoinsreceberá200 OKcom a lista vazia[]. Um fato - você não tem moedas, descrito com respostas diferentes, por quê? Eu diria que é melhor sempre pegar404 Not Found, porque não há moedas no seu bolso.GET /severalCoins. Se você determinar queGET /severalCoinsdeve devolver algumas moedas, então não deve ser 200 porque não está OK; o servidor falhou em fornecer o que o cliente deseja. Pois/singleCoinisso é óbvio porque o cliente quer exatamente uma moeda, nem mais, nem menos. É o mesmo para/coins/7. Em contraste com o/coinsterminal, normalmente os clientes não esperam nenhuma moeda, uma moeda ou várias moedas. Todos eles são respostas válidas. Se não houver moeda, é isso que eles querem. É como um emplyList<Coin>em Java, em vez denull.Eu responderia um de dois códigos, dependendo da situação do tempo de execução:
404 não encontrado)
Esta resposta é bastante correta se você não tiver mesa. Não apenas a mesa vazia, mas NENHUMA TABELA DE USUÁRIO. Ele confirma a ideia exata - nenhum recurso. Outras opções são fornecer mais detalhes PORQUE sua tabela está ausente, há alguns códigos mais detalhados, mas 404 é muito bom para se referir a situações em que você realmente não tem uma mesa.
200 (OK)
Todos os casos em que você tem tabela, mas ela está vazia ou seu processador de solicitação filtrou todos os resultados. Isso significa que 'sua solicitação está correta, tudo está OK, mas você não corresponde a nenhum dado apenas porque não temos dados ou não temos dados que correspondam à sua solicitação. Isso deve ser diferente da resposta de negação de segurança. Eu também voto para retornar 200 na situação em que você tem alguns dados e, em geral, você tem permissão para acessar a tabela, mas não tem acesso a todos os dados que correspondem à sua solicitação (os dados foram filtrados por causa da segurança no nível do objeto, mas em geral você tem permissão para solicitação).
fonte
Se você está esperando uma lista de objetos de usuário, a melhor solução é retornar uma lista vazia ([]) com 200 OK do que usar uma resposta 404 ou 204.
fonte
definitivamente retorna 200.
404 significa recurso não encontrado. Mas o recurso existe. E também, se a resposta tiver status 404. Como você pode saber a lista de usuários vazia ou preenchida?
fonte
Deve 200 OK com lista vazia.
Por que: a tabela vazia significa que a tabela existe, mas não possui nenhum registro.
404 Não encontrado significa que o ponto final solicitado não existe.
fonte