Resposta REST adequada para mesa vazia?


106

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?


19
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.
mata


2
@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.

Por que não 204 (sem conteúdo)?

Aqui está um trecho da descrição do código de status 204 por w3c

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:

<users>
  <user>
    <id>1</id>
    <name>Tom</name>
  </user>
  <user>
    <id>2</id>
    <name>IMB</name>
  </user>
</users>

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.


4
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 /severalCoins deve 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).


10

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.


2

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?


  • '/ users' se estiver vazio deve retornar '200'.
  • '/ users / 1' se o id não for encontrado. deve retornar 404.

2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.