O que Http código i deve retornar para “Coisa não encontrado”?

https://stackoverflow.com/questions/1027300

06-07-2019
|

Pergunta

eu estou construindo um serviço web que é usado, neste caso particular, para pedir informações sobre um patrono.

Vamos dizer, por uma questão de argumento, que o hit de pesquisa web é:

GET /patrons/619 HTTP/1.1

Se o patrono é encontrado, eu retornar código 200:

HTTP/1.1 200 OK

Se você omitir, ou dar um número de conta que não é um número, eu retornar 400. Por exemplo, os seguintes pedidos maus:

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/G619 HTTP/1.1
GET /patrons/kirsten%20guyer HTTP/1.1

todo o erro de retorno 400 (Bad Request), por exemplo:.

HTTP/1.1 400 Invalid patron number

Eu quero ter um código de status de patrono não encontrado , retornado como o código de status HTTP. Por exemplo:

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

Eu tenho pensado sobre o uso de 404 (não encontrado) , que é uma resposta válida (o recurso solicitado foi, realmente e verdadeiramente, não foi encontrado.) Mas eu 'm pessoas com medo de depuração que pode pensar que isso significa que eles escrito /patrons/ errado.

Alguém pode pensar em outro código de status http eu poderia usar?

Update: eu estou eyeballing

204 No Content 
The server successfully processed the request, but is not returning any content.

O que você diria?

Não se esqueça, que nem todos os servidores HTTP servir conteúdo HTML. Se um servidor web IIS é convidado para um recurso chamado:

GET /MyStartPage.html HTTP/1.1

Em seguida, o servidor HTTP tem que decidir o que responder com. Na maioria dos servidores web, um recurso chamado /MyStartPage.html corresponde a um arquivo sentados no disco rígido.

Considerando que StackOverflow faz:

GET /posts/1027301 HTTP/1.1

Que, se esse recurso não existe, o servidor web deve (com razão) retornar 404.

Solução

404 Not Found é a coisa correta a voltar, se é um serviço, não é realmente sendo usado por seres humanos, mas por máquinas, e, portanto, erros de digitação, não deve ser a sua primeira preocupação.

Além disso, há muito pouco que você vai ser capaz de fazer para o comportamento humano contra qualquer maneira (pensar uma coisa quando é realmente outra). Se você está retornando um pouco msg de erro como parte do código de erro, tudo deve funcionar. Você pode até mesmo sugerir-lhes uma possível correção.

Voltando a 500 quando o aplicativo está fazendo exatamente o que ele é projetado para fazer também parece um pouco estranho. 404 descreve exatamente a situação:. Recurso não encontrado

Outras dicas

Eu acho que você deve usar 404. Os desenvolvedores da API vai entender o que 404 meios e, portanto, vai seguir lá próprio processo de depuração de costume, a fim de resolver o problema. Vara para o protocolo.

Erro 404 é realmente uma resposta mais aceitável para este caso, porque o recurso realmente não foi encontrado. Você pode sempre ter um documento de erro personalizada que explica que é o Patrono ID que não é encontrado.

Um erro 400 significa que o cliente enviou sintaxe mal formado, o que não é o caso no seu exemplo. Assim, você não deve usar este código de erro. Pode parecer que "Bad Request" é preciso, mas o que isso realmente significa é que há um erro na sintaxe de cabeçalho de solicitação.

Isso também não é um erro 500 porque não ocorreu nenhum erro. Não há nenhum problema com o servidor web cumprir o pedido, o fato é que o pedido está buscando um recurso que não está presente.

404 é a única resposta apropriada, a menos que você considerar que um pedido plenamente válida, status de retorno 200 e uma página explicando que o Patrono solicitado não existe.

Do meu comentário original na pergunta:

Eu não acho que um erro de nível 200 seria apropriado tanto, considere as explicações na W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

IMHO, a resposta HTTP é não o lugar adequado para lidar com isso, como o erro não está no nível HTTP. É no nível do aplicativo. Uma possível solução é usar a Null Objecto Padrão retornar nulo 'Patron' em conformidade com a interface do Patrono, mas indica que tal pessoa não existe.

UPDATE: eu estive convencido de que esta resposta está errada. No entanto, quero deixar isso, pois é uma resposta potencialmente válidos (dependendo de detalhes não apresentados na pergunta), e acho que os comentários são instrutivas.

Normalmente, se o seu serviço de encontrar um erro que é incapaz de lidar, mas o pedido está bem formado, então eu acho que você gostaria de retornar um código de status 500.

Além disso, outra razão pela qual eu digo 500 seria apropriado é que a partir de minha experiência em serviços da web .NET, sempre que eu lançar uma exceção através do fio (tais como uma exceção RecordNotFound), o servidor web eo cliente sempre interpretted o resposta a ser um código de status 500.

De qualquer maneira, seria uma boa idéia para avaliar este lista http códigos de status, e multa aquele que suites suas necessidades o melhor.

Depende de qual tipo de webservice você está construindo.

SOAP e XML webservices tipicamente retornam 200 OK se um objeto solicitado (patrono) não pode ser encontrado e codificar o tipo de erro / mensagem / descrição no documento de resposta. Eles separam a nível de transporte (HTTP) a partir das mensagens trocadas (XML). Um erro 404 (que está no nível de transporte), só é devolvido, se você pedir um endpoint API não-existente (URL errado).

Com um webservice RESTO no entanto, usar HTTP métodos e status diretamente para troca de mensagens. RESTO utiliza diferentes métodos HTTP (GET / POST / PUT / DELETE) para especificar qual ação é desejado e o servidor retorna o status como o status HTTP. Portanto, no caso de um webservice REST, 404 seria o status HTTP adequada, se um patrono não pôde ser encontrado.

500 é inapropriado em qualquer caso, eu acho que, uma vez 5xx meios que houve algo de errado na serverside (que não é o caso), enquanto 4xx erros significam que há algo errado no lado do cliente.

Pode ser de 4 anos, mas ainda é muito relevante. Para APIs que são para ser usado por ambos os borwsers e aplicativos nativos, acho que é muito mais simples de usar os códigos HTTP para indicação de status. E, se necessário, use um par de códigos extras dos não atribuídos para condições que não têm um bom ajuste para existente HTTP códigos.

Erros no nível de serviço web não deve retornar apenas uma linha de status HTTP simples, mas deve, em vez retornar conteúdo em um formato válido e documentado que pode ser analisado pelo cliente acessar o seu serviço. O documento retornado deve conter um código de erro que é parte de um conjunto documentado de códigos específicos para o seu serviço web, bem como uma breve descrição do problema e descrição opcionalmente uma forma mais detalhada do problema.

Se você quiser controlar as respostas do serviço web via HTTP códigos de resposta, então você poderia realmente usar um 404 para indicar esta condição.

No entanto, eu acho que é mais natural ter a resposta do serviço de web definida inteiramente no corpo da resposta HTTP, e retornar apenas 200 para uma comunicação bem-sucedida ( "Eu entendi o seu pedido e enviou-lhe uma resposta apropriada") . Neste caso, então, você iria voltar 200 como normal com a carga útil do seu pedido (XML ou JSON ou qualquer outro), indicando que nenhuma entidade correspondente foi encontrado

eu consideraria não-200 códigos de erro semelhantes às exceções em linguagens de programação convencionais, e o corpo da resposta HTTP mais parecido com o código de retorno. Imagine se você estavam a implementar este convencionalmente - você lançar uma exceção se nenhuma entidade foi encontrado, ou null retorno? Pessoalmente, dada a natureza frágil de conexões de rede, eu gostaria de reservar todos os códigos de erro HTTP de nível de problemas na comunicação, e eu prefiro sempre voltar 200 OK do próprio serviço, juntamente com uma carga útil especificando o resultado ou qualquer serviço erro -level.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow