Qual é o código de resposta REST adequado para uma solicitação válida, exceto dados vazios?

Por exemplo, você executa uma solicitação GET, users/9mas não há usuário com o ID nº 9. Qual é o melhor código de resposta?

• 200 OK
• 202 Aceito
• 204 Sem Conteúdo
• 400 Solicitação incorreta
• 404 não encontrado

TL; DR: uso 404

Veja este blog . Isso explica muito bem.

Resumo dos comentários do blog em 204 :

1. 204 No Content não é muito útil como código de resposta para um navegador (embora, de acordo com as especificações HTTP, os navegadores precisem entendê-lo como um código de resposta 'não mude a exibição').
2. 204 No Content é , no entanto, muito útil para serviços da web ajax, que podem indicar sucesso sem precisar retornar algo. (Especialmente em casos como DELETEouPOST s que não requerem o feedback).

A resposta, portanto, à sua pergunta é usada 404no seu caso. 204é um código de resposta especializado que você geralmente não deve retornar a um navegador em resposta a umGET .

Os outros códigos de resposta que são ainda menos adequados que 204e 404:

1. 200deve ser devolvido com o corpo do que você buscou com sucesso. Não é apropriado quando a entidade que você está buscando não existe.
2. 202é usado quando o servidor começa a trabalhar em um objeto, mas o objeto ainda não está totalmente pronto. Certamente não é o caso aqui. Você não iniciou, nem começará a construção do usuário 9 em resposta a umaGET solicitação. Isso quebra todos os tipos de regras.
3. 400é usado em resposta a uma solicitação HTTP mal formatada (por exemplo, cabeçalhos http malformados, segmentos ordenados incorretamente etc.). Isso quase certamente será tratado por qualquer estrutura que você esteja usando. Você não deveria ter que lidar com isso, a menos que esteja escrevendo seu próprio servidor do zero. Editar : RFCs mais recentes agora permitem que 400 sejam usados ​​para solicitações semanticamente inválidas.

A descrição dos códigos de status HTTP da Wikipedia é particularmente útil. Você também pode ver as definições no documento HTTP / 1.1 RFC2616 em www.w3.org

Oponho-me fortemente a 404 a favor de 204 ou 200 com dados vazios. Ou pelo menos um deve usar uma entidade de resposta com o 404.

A solicitação foi recebida e processada adequadamente - ela acionou o código do aplicativo no servidor, portanto, não se pode realmente dizer que foi um erro do cliente e, portanto, toda a classe de códigos de erro do cliente (4xx) não é adequada.

Mais importante, o 404 pode acontecer por vários motivos técnicos. Por exemplo, o aplicativo sendo temporariamente desativado ou desinstalado no servidor, problemas de conexão de proxy e outros enfeites. Portanto, o cliente não pode distinguir entre um 404 que significa "conjunto de resultados vazio" e um 404 que significa "o serviço não pode ser encontrado, tente novamente mais tarde".

Isso pode ser fatal: imagine um serviço de contabilidade em sua empresa que lista todos os funcionários que recebem um bônus anual. Infelizmente, a única vez em que é chamada retorna um 404. Isso significa que ninguém recebe um bônus ou que o aplicativo está atualmente inativo para uma nova implantação?

-> Para aplicativos que se preocupam com a qualidade de seus dados, o 404 sem entidade de resposta é, portanto, praticamente inútil.

Além disso, muitas estruturas de clientes respondem a um 404 lançando uma exceção sem mais perguntas. Isso força o desenvolvedor do cliente a capturar essa exceção, avaliá-la e decidir com base nisso se deve registrá-la como um erro detectado por, por exemplo, um componente de monitoramento ou se deve ignorá-la. Isso também não parece bonito para mim.

A vantagem de 404 sobre 204 é que ele pode retornar uma entidade de resposta que pode conter algumas informações sobre o motivo pelo qual o recurso solicitado não foi encontrado. Mas, se isso realmente for relevante, pode-se considerar o uso de uma resposta 200 OK e projetar o sistema de maneira a permitir respostas de erro nos dados da carga útil. Como alternativa, pode-se usar a carga útil da resposta 404 para retornar informações estruturadas ao chamador. Se ele recebe, por exemplo, uma página html em vez de XML ou JSON que ele pode analisar, é um bom indicador de que algo técnico deu errado em vez de uma resposta "sem resultado" que pode ser válida do ponto de vista do chamador. Ou pode-se usar um cabeçalho de resposta HTTP para isso.

Ainda assim, eu preferiria um 204 ou 200 com resposta vazia. Dessa forma, o status da execução técnica da solicitação é separado do resultado lógico da solicitação. 2xx significa "execução técnica ok, este é o resultado, lide com isso".

Penso que, na maioria dos casos, deve ser deixado ao cliente decidir se um resultado vazio é aceitável ou não. Ao retornar 404 sem entidade de resposta, apesar de uma execução técnica correta, o cliente pode decidir considerar os casos como erros que simplesmente não são erros.

Outra analogia rápida: retornar 404 para "nenhum resultado encontrado" é como lançar um DatabaseConnectionException se uma consulta SQL não retornar resultados. Ele pode fazer o trabalho, mas há muitas causas técnicas possíveis que lançam a mesma exceção, que seriam confundidas com um resultado válido.

No começo, pensei que um 204 faria sentido, mas após as discussões, acredito que 404 é a única resposta correta verdadeira. Considere os seguintes dados:

Usuários: John, Peter

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /users/kyle              404     Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

Alguns antecedentes:

1. a pesquisa retorna uma matriz, mas não possui correspondências, mas tem conteúdo: uma matriz vazia .

2. Naturalmente, 404 é mais conhecido por URLs que não são suportados pelo servidor solicitado, mas um recurso ausente é o mesmo.
   Mesmo /users/:namecombinando com users/kyle, o usuário Kyle não está disponível, portanto um 404 ainda se aplica. Não é uma consulta de pesquisa, é uma referência direta por um URL dinâmico , portanto 404.

Enfim, meus dois centavos :)

Se é esperado que o recurso exista, mas possa estar vazio, eu diria que talvez seja mais fácil obter um OK 200 com uma representação que indique que o item está vazio.

Então, eu preferiria que as coisas retornassem 200 OK com {"Items": []} do que 204 com nada, porque dessa maneira uma coleção com 0 itens pode ser tratada da mesma forma que uma coleção com um ou mais itens. mais item nele.

Gostaria apenas de deixar o 204 No Content for PUTs e DELETEs, onde pode ser o caso de realmente não haver representação útil.

No caso de / coisa / 9 realmente não existir, um 404 é apropriado.

Em projetos anteriores, usei 404. Se não houver usuário 9, o objeto não foi encontrado. Portanto, 404 não encontrado é apropriado.

Para o objeto existe, mas não há dados, 204 Nenhum Conteúdo seria apropriado. Eu acho que no seu caso, o objeto ainda não existe.

De acordo com o post do w3 ,

200 OK

A solicitação foi bem sucedida. As informações retornadas com a resposta dependem do método usado na solicitação

202 Aceito

A solicitação foi aceita para processamento, mas o processamento não foi concluído.

204 Sem Conteúdo

O servidor atendeu à solicitação, mas não precisa retornar um corpo de entidade e pode querer retornar metainformações atualizadas.

400 Solicitação incorreta

A solicitação não pôde ser entendida pelo servidor devido à sintaxe incorreta. O cliente NÃO DEVE repetir o pedido sem modificações

401 não autorizado

A solicitação requer autenticação do usuário. A resposta DEVE incluir um campo de cabeçalho WWW-Authenticate

404 não encontrado

O servidor não encontrou nada que corresponda ao Request-URI. Nenhuma indicação é dada se a condição é temporária ou permanente

Para resumir ou simplificar,

2xx: Dados opcionais: URI bem formado: os critérios não fazem parte do URI: se o critério for opcional, pode ser especificado em @RequestBody e @RequestParam deve levar a 2xx. Exemplo: filtrar por nome / status

4xx: dados esperados: URI não bem formado: os critérios fazem parte do URI: se os critérios forem obrigatórios e só puderem ser especificados em @PathVariable, deverão resultar em 4xx. Exemplo: pesquisa por ID exclusivo.

Assim, para a situação solicitada: "users / 9" seria 4xx (possivelmente 404). Mas para "users? Name = superman" deveria ser 2xx (possivelmente 204).

Há duas perguntas. Um no título e outro no exemplo. Eu acho que isso levou em parte à quantidade de controvérsias sobre qual resposta é apropriada.

O título da pergunta pergunta sobre dados vazios. Dados vazios ainda são dados, mas não são iguais a nenhum dado. Portanto, isso sugere solicitar um conjunto de resultados, ou seja, uma lista, talvez de/users . Se uma lista estiver vazia, ainda será uma lista, portanto, um 204 (Sem Conteúdo) é o mais apropriado. Você acabou de pedir uma lista de usuários e recebeu um, por acaso não possui conteúdo.

O exemplo fornecido, em vez disso, pergunta sobre um objeto específico, um usuário /users/9,. Se o usuário nº 9 não for encontrado, nenhum objeto de usuário será retornado. Você solicitou um recurso específico (um objeto de usuário) e não recebeu porque não foi encontrado; portanto, um 404 é apropriado.

Eu acho que a maneira de resolver isso é se você pode usar a resposta da maneira que esperaria sem adicionar nenhuma declaração condicional; em seguida, use um 204, caso contrário, use um 404.

Nos meus exemplos, eu posso percorrer uma lista vazia sem verificar se há conteúdo, mas não consigo exibir dados do objeto de usuário em um objeto nulo sem quebrar algo ou adicionar uma verificação para verificar se é nula.

Obviamente, você poderia retornar um objeto usando o padrão de objeto nulo, se isso atender às suas necessidades, mas isso for uma discussão para outro encadeamento.

Depois de analisar a questão, você não deve usar o 404porquê?

Com base na RFC 7231, o código de status correto é204

Nas respostas acima, notei um pequeno mal-entendido:

1.- o recurso é: /users

2.- /users/8não é o recurso, é este: o recurso /userscom parâmetro de rota8 , o consumidor talvez não consiga percebê-lo e não saiba a diferença, mas o editor conhece e deve saber disso! ... portanto, ele deve retornar uma resposta precisa para os consumidores. período.

tão:

Com base no RFC: 404 está incorreto porque os recursos foram /usersencontrados, mas a lógica executada usando o parâmetro 8não encontrou nenhum contentretorno como resposta, portanto, a resposta correta é:204

O ponto principal aqui é: 404nem mesmo o recurso foi encontrado para processar a lógica interna

204é um: Encontrei o recurso, a lógica foi executada, mas não encontrei nenhum dado usando seus critérios dados no parâmetro route, portanto não posso retornar nada para você. Desculpe, verifique seus critérios e ligue para mim novamente.

200: ok, encontrei o recurso, a lógica foi executada (mesmo quando não sou obrigada a retornar nada) pegue isso e use-o à sua vontade.

205: (a melhor opção de uma resposta GET) Encontrei o recurso, a lógica foi executada, tenho algum conteúdo para você, use-o bem, a propósito, se você deseja compartilhar isso em uma visualização, atualize a visualização para exibi-lo.

Espero que ajude.

O que as respostas existentes não elaboram é que faz diferença se você usa parâmetros de caminho ou parâmetros de consulta.

• No caso de parâmetros do caminho, o parâmetro faz parte do caminho do recurso. No caso de /users/9, a resposta deve ser 404porque esse recurso não foi encontrado. /users/9é o recurso e o resultado é unário ou um erro, ele não existe. Esta não é uma mônada.
• No caso de parâmetros de consulta, o parâmetro não faz parte do caminho do recurso. No caso de /users?id=9, a resposta deve ser 204porque o recurso /usersfoi encontrado, mas não pôde retornar nenhum dado. O recurso /usersexiste e o resultado é n-ário, existe mesmo se estiver vazio. Se idfor único, é uma mônada.

A utilização de parâmetros de caminho ou de consulta depende do caso de uso. Prefiro parâmetros de caminho para argumentos obrigatórios, normativos ou de identificação e parâmetros de consulta para argumentos opcionais, não normativos ou de atribuição (como paginação, local de agrupamento e outras coisas). Em uma API REST, eu usaria /users/9não /users?id=9especialmente por causa do possível aninhamento para obter "registros filhos", como /users/9/ssh-keys/0obter a primeira chave pública ssh ou /users/9/address/2o terceiro endereço postal.

Eu prefiro usar 404. Aqui está o porquê:

• Os pedidos de métodos unários (1 resultado) e n-ário (n resultados) não devem variar sem um bom motivo. Eu gosto de ter os mesmos códigos de resposta, se possível. O número de resultados esperados é obviamente uma diferença, digamos, que você espera que o corpo seja um objeto (unário) ou uma matriz de objetos (n-ária).
• Para n-ária, eu retornaria uma matriz e, caso não houvesse resultados, não retornaria nenhum conjunto (sem documento), retornaria um conjunto vazio (documento vazio, como matriz vazia em JSON ou elemento vazio em XML ) Ou seja, ainda são 200, mas com zero registro. Não há razão para colocar essas informações no fio, a não ser no corpo.
• 204é como um voidmétodo. Eu não iria usá-lo para GET, apenas para POST, PUTe DELETE. Eu faço uma exceção no caso de GETonde os identificadores são parâmetros de consulta e não parâmetros de caminho.
• Não encontrar o registro é como NoSuchElementException, ArrayIndexOutOfBoundsExceptionou algo parecido, causado pelo cliente usando um ID que não existe, portanto, é um erro do cliente.
• De uma perspectiva de código, obter 204significa uma ramificação adicional no código que poderia ser evitada. Isso complica o código do cliente e, em alguns casos, também o código do servidor (dependendo de você usar mônadas de entidade / modelo ou entidades / modelos simples; e eu recomendo fortemente ficar longe das mônadas de entidade / modelo, pois isso pode levar a erros desagradáveis, porque da mônada, você acha que uma operação é bem-sucedida e retorna 200 ou 204 quando você realmente deveria ter retornado outra coisa).
• É mais fácil escrever e entender o código do cliente se 2xx significa que o servidor fez o que o cliente solicitou e 4xx significa que o servidor não fez o que o cliente solicitou e a culpa é do cliente. Não fornecer ao cliente o registro de que o cliente solicitado pelo ID é culpa do cliente, porque ele solicitou um ID que não existe.

Por último, mas não menos importante: Consistência

• GET /users/9
• PUT /users/9 e DELETE /users/9

PUT /users/9e DELETE /users/9já precisa retornar 204em caso de atualização ou exclusão bem-sucedida. Então, o que eles devem retornar caso o usuário 9 não exista? Não faz sentido ter a mesma situação apresentada como códigos de status diferentes, dependendo do método HTTP usado.

Além disso, não é uma razão normativa, mas cultural: se 204for usada para a GET /users/9próxima coisa que acontecerá no projeto é que alguém acha que retornar 204é bom para métodos n-ários. E isso complica o código do cliente, porque, em vez de apenas 2xxprocurar 204e decodificar o corpo, o cliente agora precisa procurar especificamente e, nesse caso, pular a decodificação do corpo. Brotar o que o cliente faz em seu lugar? Criar uma matriz vazia? Por que não ter isso no fio, então? Se o cliente cria a matriz vazia, 204 é uma forma de compactação estúpida. Se o cliente usar null, uma lata de worms totalmente diferente será aberta.

O Twitter usa 404 com uma mensagem de erro personalizada como "Nenhum dado encontrado".

Ref: https://developer.twitter.com/en/docs/basics/response-codes.html

204 é mais apropriado. Especialmente quando você tem um sistema de alerta para garantir a segurança do site, o 404 nesse caso causaria confusão, porque você não sabe que alguns alertas 404 são erros de back-end ou solicitações normais, mas a resposta está vazia.

Eu diria que nenhum deles é realmente apropriado. Como foi dito - por exemplo, por @anneb, eu também acho que parte dos problemas surge do uso de um código de resposta HTTP para transportar um status relacionado a um serviço RESTful. Tudo o que o serviço REST tem a dizer sobre seu próprio processamento deve ser transportado por meio de códigos específicos do REST.

1

Eu diria que, se o servidor HTTP encontrar algum serviço pronto para responder a uma solicitação que foi enviada, ele não deverá responder com um HTTP 404 - no final, algo foi encontrado pelo servidor - a menos que seja explicitamente explicado pelo serviço que processa a solicitação.

Vamos assumir por um momento o seguinte URL: http://example.com/service/return/test.

• O caso A é que o servidor está "simplesmente procurando o arquivo no sistema de arquivos". Se não estiver presente, 404está correto. O mesmo é verdade, se ele solicitar algum tipo de serviço para entregar exatamente esse arquivo e esse serviço informar que não existe esse nome.
• No caso B, o servidor não funciona com arquivos "reais", mas na verdade a solicitação é processada por algum outro serviço - por exemplo, algum tipo de sistema de modelagem. Aqui, o servidor não pode fazer nenhuma reivindicação sobre a existência do recurso, pois não sabe nada sobre ele (a menos que seja informado pelo serviço que o manipula).

Sem qualquer resposta do serviço que exija explicitamente um comportamento diferente, o servidor HTTP pode dizer apenas três coisas:

• 503 se o serviço que deveria lidar com a solicitação não estiver em execução ou respondendo;
• 200 caso contrário, como o servidor HTTP pode realmente atender à solicitação - não importa o que o serviço dirá posteriormente;
• 400ou 404para indicar que não existe esse serviço (em vez de "existe, mas está offline") e nada mais foi encontrado.

2

Voltando à questão em questão: acho que a abordagem mais limpa seria não usar nenhum código de resposta HTTP além do que foi dito anteriormente. Se o serviço estiver presente e respondendo, o código HTTP deve ser 200. A resposta deve conter o status que o serviço retornou em um cabeçalho separado - aqui, o serviço pode dizer

• REST:EMPTYpor exemplo, se foi solicitado a procurar sth. e que a pesquisa retornou vazia;
• REST:NOT FOUNDse foi solicitado especificamente para sth. “Tipo ID” - seja um nome de arquivo ou um recurso por ID ou entrada nº 24, etc. - e esse recurso específico não foi encontrado (geralmente, um recurso específico foi solicitado e não encontrado);
• REST:INVALID se alguma parte da solicitação que foi enviada não for reconhecida pelo serviço.

(observe que eu os prefixei com "REST:" de propósito para marcar o fato de que, embora possam ter os mesmos valores ou palavras que os códigos de resposta HTTP, eles são completamente diferentes)

3

Vamos voltar ao URL acima e inspecionar o caso B em que o serviço indica ao servidor HTTP que ele não processa essa solicitação em si, mas a repassa SERVICE. O HTTP serve apenas o que é devolvido SERVICE, ele não sabe nada sobre a return/testparte em que é entregue SERVICE. Se esse serviço estiver em execução, o HTTP deverá retornar 200, pois de fato encontrou algo para lidar com a solicitação.

O status retornado por SERVICE(e que, como dito acima, gostaria de ver em um cabeçalho separado) depende de qual ação é realmente esperada:

• se return/testsolicita um recurso específico: se existir, retorne-o com um status de REST:FOUND; se esse recurso não existir, retorne REST:NOT FOUND; isso poderia ser estendido para retornar REST:GONEse soubermos que ela já existia e não voltará, e REST:MOVEDse sabemos que se tornou hollywood
• se return/testfor considerada uma operação de pesquisa ou semelhante a filtro: se o conjunto de resultados estiver vazio, retorne um conjunto vazio no tipo solicitado e no status de REST:EMPTY; um conjunto de resultados no tipo solicitado e um status deREST:SUCCESS
• se return/testnão for uma operação reconhecida por SERVICE: retorne REST:ERRORse estiver completamente errada (por exemplo, um erro de digitação retrun/test), ou REST:NOT IMPLEMENTEDcaso esteja planejada para mais tarde.

4

Essa distinção é muito mais limpa do que misturar as duas coisas diferentes. Isso também tornará a depuração mais fácil e o processamento apenas um pouco mais complexo, se houver.

• Se um HTTP 404 for retornado, o servidor me dirá: "Não faço ideia do que você está falando". Embora a parte REST da minha solicitação esteja perfeitamente correta, estou procurando par'Mach em todos os lugares errados.
• Por outro lado, o HTTP 200 e o REST: ERR informam que eu obtive o serviço, mas fiz algo errado na minha solicitação ao serviço.
• Do HTTP 200 e REST: VAZIO, sei que não fiz nada errado - servidor certo, o servidor encontrou o serviço, solicitação correta para o serviço - mas o resultado da pesquisa está vazio.

Resumo

O problema e a discussão decorrem do fato de que os códigos de resposta HTTP estão sendo usados ​​para indicar o estado de um serviço cujos resultados são atendidos por HTTP ou para indicar sth. isso não está no escopo do próprio servidor HTTP. Devido a essa discrepância, a pergunta não pode ser respondida e todas as opiniões estão sujeitas a muita discussão.

O estado de uma solicitação processada por um serviço e não pelo servidor HTTP REALMENTE NÃO (RFC 6919) deve ser fornecido por um código de resposta HTTP. O código HTTP DEVE (RFC 2119) conter apenas as informações que o servidor HTTP pode fornecer a partir de seu próprio escopo: a saber, se o serviço foi encontrado para processar a solicitação ou não.

Em vez disso, uma maneira diferente deve ser usada para informar um consumidor sobre o estado da solicitação para o serviço que está realmente processando a solicitação. Minha proposta é fazê-lo através de um cabeçalho específico. Idealmente, o nome do cabeçalho e seu conteúdo seguem um padrão que facilita o trabalho dos consumidores com essas respostas.

De acordo com o RFC7231 - page59 ( https://tools.ietf.org/html/rfc7231#page-59 ), a definição de resposta do código de status 404 é:

6.5.4 404 não encontrado O código de status 404 (não encontrado) indica que o servidor de origem não encontrou uma representação atual para o recurso de destino ou não está disposto a divulgar que existe. Um código de status 404 não indica se essa falta de representação é temporária ou permanente; o código de status 410 (Gone) é preferido sobre 404, se o servidor de origem souber, presumivelmente por alguns meios configuráveis, que a condição provavelmente será permanente. Uma resposta 404 é armazenável em cache por padrão; isto é, a menos que indicado de outra forma pela definição do método ou pelos controles explícitos de cache (consulte a Seção 4.2.2 de [RFC7234]).

E o principal que traz dúvidas é a definição de recurso no contexto acima. De acordo com a mesma RFC (7231), a definição de recurso é:

Recursos: o destino de uma solicitação HTTP é chamado de "recurso". HTTP não limita a natureza de um recurso; apenas define uma interface que pode ser usada para interagir com recursos. Cada recurso é identificado por um URI (Uniform Resource Identifier), conforme descrito na Seção 2.7 da [RFC7230]. Quando um cliente constrói uma mensagem de solicitação HTTP / 1.1, ele envia o URI de destino em um dos vários formulários, conforme definido na (Seção 5.3 de [RFC7230]). Quando uma solicitação é recebida, o servidor reconstrói um URI de solicitação eficaz para o recurso de destino (Seção 5.5 de [RFC7230]). Um objetivo do projeto do HTTP é separar a identificação de recursos da semântica de solicitação, o que é possível investindo a semântica de solicitação no método de solicitação (Seção 4) e alguns campos de cabeçalho de modificação de solicitação (Seção 5).

Portanto, no meu entender, o código de status 404 não deve ser usado em uma solicitação GET bem-sucedida com resultado vazio. (Exemplo: uma lista sem resultado para filtro específico)

Tais coisas podem ser subjetivas e há alguns argumentos interessantes e vários sólidos de ambos os lados. No entanto [na minha opinião], retornar um 404 por dados ausentes não está correto . Aqui está uma descrição simplificada para deixar isso claro:

• Pedido: Posso ter alguns dados, por favor?
• Recurso (ponto de extremidade da API): receberei essa solicitação para você aqui [envia uma resposta de dados em potencial]

Nada quebrou, o terminal foi encontrado e a tabela e as colunas foram localizadas, de modo que o banco de dados consultado e os dados foram "retornados" com sucesso!

Agora - se essa "resposta bem-sucedida" possui dados ou não, não importa, você solicitou uma resposta de dados "potenciais" e essa resposta com dados "potenciais" foi atendida. Nulo, vazio etc. são dados válidos.

200 significa apenas que qualquer solicitação que fizemos foi bem-sucedida. Estou solicitando dados, nada deu errado com o HTTP / REST e, como os dados (embora vazios) foram retornados, minha "solicitação de dados" foi bem-sucedida.

Retorne 200 e deixe o solicitante lidar com dados vazios, conforme cada cenário específico o justifique!

Considere este exemplo:

• Pedido: consulta a tabela "infrações" com o ID do usuário 1234
• Recurso (ponto de extremidade da API): retorna uma resposta, mas os dados estão vazios

Esses dados vazios são totalmente válidos. Isso significa que o usuário não possui infrações. Este é um 200, pois é tudo válido, como então eu posso fazer:

Você não tem infrações, tem um muffin de mirtilo!

Se você considera 404 o que está afirmando? Não foi possível encontrar as infrações do usuário? Agora, gramaticalmente, isso está correto, mas simplesmente não está correto no mundo REST, quando o sucesso ou o fracasso é sobre a solicitação. Os dados de "infração" para este usuário foram encontrados com sucesso, existem zero infrações - um número real que representa um estado válido.

[Nota atrevida ..]

No seu título, você concorda subconscientemente que 200 é a resposta correta:

Qual é o código de resposta REST adequado para uma solicitação válida, exceto dados vazios?

Aqui estão algumas coisas a considerar ao escolher qual código de status usar, independentemente da subjetividade e das escolhas complicadas:

1. Consistência . Se você usar 404 para "sem dados", use-o sempre que uma resposta retornar nenhum dado.
2. Não use o mesmo status para mais de um significado . Se você retornar 404 quando um recurso não foi encontrado (por exemplo, o ponto final da API não existe, etc.), também não o use para nenhum dado retornado. Isso apenas torna difícil lidar com as respostas.
3. Considere o contexto cuidadosamente . Qual é o "pedido"? O que você está dizendo que está tentando alcançar?

Codifique o conteúdo da resposta com uma enumeração comum que permita ao cliente ativá-lo e dividir a lógica de acordo. Não tenho certeza de como seu cliente distinguiria a diferença entre um "dado não encontrado" 404 e um "recurso da web não encontrado" 404? Você não deseja que alguém navegue até o usuário Z / 9 e faça com que o cliente se pergunte como se a solicitação fosse válida, mas não houvesse dados retornados.

Por que não usar 410? Isso sugere que o recurso solicitado não existe mais e que o cliente nunca deve fazer uma solicitação para esse recurso, no seu caso users/9.

Você pode encontrar mais detalhes sobre o 410 aqui: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

É triste que algo tão simples e bem definido tenha se tornado "baseado em opiniões" neste tópico.

Um servidor HTTP conhece apenas "entidades", que é uma abstração para qualquer conteúdo, seja uma página estática da Web, uma lista de resultados de pesquisa, uma lista de outras entidades, uma descrição json de algo, um arquivo de mídia, etc.

Espera-se que cada uma dessas entidades seja identificável por um URL exclusivo, por exemplo

• / user / 9 - uma única entidade: um USER ID = 9
• / users - uma única entidade: uma lista de todos os usuários
• /media/x.mp3 - uma única entidade: um arquivo de mídia chamado x.mp3
• / search - uma única entidade: um CONTEÚDO dinâmico baseado em parâmetros de consulta

Se um servidor encontrar um recurso pelo URL fornecido, não importa qual seja seu conteúdo - 2G de dados, nulo, {}, [] - enquanto existir, será 200. Mas se essa entidade for não é conhecido pelo servidor, espera-se retornar 404 "Não encontrado".

Parece haver uma confusão de desenvolvedores que pensam que, se o aplicativo possui um manipulador para um determinado formato de caminho, não deve haver erro. Aos olhos do protocolo HTTP, não importa o que aconteceu nas partes internas do servidor (ou seja, se o roteador padrão respondeu ou um manipulador para um formato de caminho específico), desde que não haja uma entidade correspondente no servidor para o servidor. URL solicitada (que solicitou arquivo MP3, página da web, objeto de usuário etc.), que retornaria conteúdo válido (vazio ou não), deve ser 404 (ou 410 etc.).

Outro ponto de confusão parece estar em torno de "sem dados" e "sem entidade". O primeiro é sobre o conteúdo de uma entidade, e o último sobre a sua existência.

Exemplo 1:

• Sem dados: / users retorna 200 OK, corpo: [] porque ninguém se registrou ainda
• Nenhuma entidade: / users retorna 404 porque não há caminho / usuários

Exemplo 2:

• Sem dados: / user / 9 retorna retorno 200 OK, corpo: {}, porque o ID do usuário = 9 nunca inseriu seus dados pessoais
• Nenhuma entidade: / user / 9 retorna 404 porque não há um ID de usuário = 9

Exemplo 3:

• Sem dados: / search? Name = Joe retorna 200 OK [], porque não há Joe no banco de dados
• Nenhuma entidade: / search? Name = Joe retorna 404 porque não há caminho / pesquisa

404 seria muito confuso para qualquer cliente se você retornar apenas porque não há dados em resposta.

Para mim, o Código de Resposta 200 com um corpo vazio é suficiente para entender que tudo está perfeito, mas não há dados correspondentes aos requisitos.

De acordo com a Microsoft: Tipos de retorno de ação do controlador na API da web do ASP.NET Core , role para baixo quase até o final, você encontrará o seguinte resumo sobre 404 relacionado a um objeto não encontrado no banco de dados. Aqui eles sugerem que um 404 é apropriado para dados vazios.

Conforme declarado por muitos, 404 é enganoso e não permite ao cliente discriminar se o uri da solicitação não existe ou se o uri solicitado não pode buscar o recurso solicitado.

Espera-se que o status 200 contenha dados de recursos - portanto, não é a escolha certa. O status 204 significa algo totalmente diferente e não deve ser usado como resposta para solicitações GET.

Todos os outros status existentes não são aplicáveis, por um motivo ou por outro.

Eu já vi esse tópico discutido várias vezes em vários lugares. Para mim, é dolorosamente óbvio que, para eliminar a confusão em torno do tópico, é necessário um status de sucesso dedicado. Algo como " 209 - Nenhum recurso para exibir".

Será um status 2xx porque não encontrar um ID não deve ser considerado um erro do cliente (se os clientes soubessem tudo o que está no banco de dados do servidor, eles não precisariam pedir nada ao servidor, não?). Esse status dedicado abordará todos os problemas debatidos com o uso de outros status.

A única pergunta é: como faço para que o RFC aceite isso como padrão?