O que é um código de status HTTP apropriado para retornar por um serviço da API REST para uma falha de validação?


394

Atualmente, estou retornando 401 não autorizado sempre que encontro uma falha de validação no meu aplicativo REST API baseado em Django / Piston . Tendo examinado o Registro de Código de Status HTTP, não estou convencido de que este seja um código apropriado para uma falha na validação, o que vocês recomendam?

  • 400 Solicitação incorreta
  • 401 não autorizado
  • 403 Proibido
  • 405 Método não permitido
  • 406 Não aceitável
  • Falha na pré-condição 412
  • 417 Expectativa falhada
  • 422 Entidade não processável
  • 424 Dependência com falha

Atualização : "Falha na validação" acima significa uma falha na validação de dados no nível do aplicativo, ou seja, data e hora especificadas incorretamente, endereço de e-mail falso etc.



3
Fwiw, o link de Kenny sugere o código 422, como a resposta de Jim agora faz abaixo . #TheMoreYouKnow #SavingYouAClick
Ruffin

Eu acho que 401 é mais claro.
insira

Respostas:


298

Se "falha na validação" significa que há algum erro do cliente na solicitação, use HTTP 400 (Solicitação incorreta). Por exemplo, se o URI tiver uma data ISO-8601 e você achar que está no formato errado ou se referir a 31 de fevereiro, retornaria um HTTP 400. Idem se você espera XML bem formado no corpo de uma entidade e falha ao analisar.

(1/2016): Nos últimos cinco anos , o HTTP 422 (entidade não processável) mais específico do WebDAV se tornou uma alternativa muito razoável ao HTTP 400. Veja, por exemplo, seu uso na API JSON . Mas observe que o HTTP 422 não chegou ao HTTP 1.1, RFC-7231 .

O RESTful Web Services de Richardson e Ruby contém um apêndice muito útil sobre quando usar os vários códigos de resposta HTTP. Eles dizem:

400 ("Solicitação incorreta")
Importância: alta.
Esse é o status de erro genérico do lado do cliente, usado quando nenhum outro código de erro 4xx é apropriado. É comumente usado quando o cliente envia uma representação junto com uma solicitação PUT ou POST, e a representação está no formato certo, mas não faz sentido. (p. 381)

e:

401 (“Não autorizado”)
Importância: Alta.
O cliente tentou operar em um recurso protegido sem fornecer as credenciais de autenticação adequadas. Pode ter fornecido as credenciais erradas, ou nenhuma. As credenciais podem ser um nome de usuário e senha, uma chave de API ou um token de autenticação - independentemente do serviço em questão. É comum que um cliente faça uma solicitação de um URI e aceite um 401 apenas para saber que tipo de credenciais enviar e em que formato. [...]


3
Mas provavelmente se o formato URI for inválido, um 404 pode ser mais apropriado.
manu

11
Conforme afirmado por @ReWrite, também acho que 422 é melhor para erros de validação.
Panteo

11
Eu diria que isso está errado. 400 Solicitação incorreta é usada quando há algo sintaticamente errado com a solicitação. Eu diria que ReWrite está certo ao recomendar 422, que trata do conteúdo da solicitação.
Stijn de Witt

3
@Kenji sim, 401 (“Não autorizado”): "Pode ter fornecido as credenciais erradas ..." significa usuário e / ou senha incorretos.
Razzintown

4
Os erros do @JimFerrans 400 são para onde a sintaxe fornecida está incorreta. Os erros 401 são especificamente se estou tentando acessar uma página na qual preciso estar logado para acessar e não estou logado. 422 erros são para onde a sintaxe está correta, mas o servidor está recusando o serviço. Nome de usuário / senha incorretos estão com a sintaxe correta (não com erro 400) e não estou tentando acessar uma página na qual preciso fazer login, porque estou acessando a própria página de login (não com erro 401). O erro 401 deve ser usado para algo como uma página de configurações que somente um usuário pode acessar
Zachary Weixelbaum

98

Do RFC 4918 (e também documentado em http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

O código de status 422 (Entidade não processável) significa que o servidor entende o tipo de conteúdo da entidade solicitada (portanto, um código de status 415 (Tipo de mídia não suportado) é inadequado) e a sintaxe da entidade solicitada está correta (portanto, 400 (Solicitação incorreta) ) código de status é inapropriado), mas não conseguiu processar as instruções contidas. Por exemplo, essa condição de erro pode ocorrer se um corpo de solicitação XML contiver instruções XML bem formadas (ou seja, sintaticamente corretas), mas semanticamente erradas.


6
Eu recomendaria 422 - Unprocessable Entidade para falhas de validação mais de 400 - Bad Request
java_geek


19

Aqui está:

rfc2616 # section-10.4.1 - 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.

rfc7231 # section-6.5.1 - 6.5.1. 400 Solicitação incorreta

O código de status 400 (Solicitação incorreta ) indica que o servidor não pode ou não processará a solicitação devido a algo que é percebido como um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválida ou roteamento de solicitação enganoso) .

Refere-se a casos malformados (não bem formados)!

rfc4918 - 11.2. 422 Entidade não processável

O código de status 422 (Entidade não processável) significa que o servidor
entende o tipo de conteúdo da entidade de solicitação (portanto, um código de status 415 (Tipo de mídia não suportado) é inapropriado) e a sintaxe da entidade de solicitação está correta (portanto, 400 (Solicitação incorreta) ) código de status é inadequado), mas não conseguiu processar as instruções contidas. Por exemplo, essa condição de erro pode ocorrer se um corpo de solicitação XML contiver instruções XML bem formadas (ou seja, sintaticamente corretas), mas semanticamente erradas .

Conclusão

Regra geral: [_] 00 cobre o caso mais geral e os casos que não são cobertos pelo código designado.

422 se encaixa no melhor erro de validação de objeto (justamente minha recomendação :)
Quanto a semanticamente errôneo - Pense em algo como a validação "Este nome de usuário já existe".

400 é usado incorretamente para validação de objeto


9

Eu diria que tecnicamente pode não ser uma falha HTTP, já que o recurso foi (presumivelmente) especificado de forma válida, o usuário foi autenticado e não houve falha operacional (no entanto, a especificação inclui alguns códigos reservados, como 402 Payment Required, que não são ' estritamente falando relacionado ao HTTP, embora possa ser aconselhável tê-lo no nível do protocolo para que qualquer dispositivo possa reconhecer a condição).

Se esse for realmente o caso, eu adicionaria um campo de status à resposta com erros de aplicativo, como

<status><code>4</code> <message> O período é inválido </message> </status>


1

Há um pouco mais de informações sobre a semântica desses erros no RFC 2616 , que documenta o HTTP 1.1.

Pessoalmente, eu provavelmente usaria 400 Bad Request, mas esta é apenas a minha opinião pessoal, sem qualquer apoio factual.


0

O que exatamente você quer dizer com "falha na validação"? O que você está validando? Você está se referindo a algo como um erro de sintaxe (por exemplo, XML malformado)?

Se for esse o caso, eu diria que 400 Bad Request é provavelmente a coisa certa, mas sem saber o que você está "validando", é impossível dizer.


e se estamos tentando validar algumas regras ou validação de negócios.
Metalhead
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.