Código de resposta REST para dados inválidos

Qual código de resposta deve ser passado para o cliente nos seguintes cenários?

1. Dados inválidos transmitidos durante o registro do usuário, como formato de email errado
2. O nome de usuário / email já existe

Eu escolhi 403. Eu também achei a seguir que acho que pode ser usado.

Wikipedia:

Falha na pré-condição 412: o servidor não atende a uma das pré-condições que o solicitante colocou na solicitação

Sugira código se devo usar outro que não seja 403.

400 é a melhor escolha nos dois casos. Se você deseja esclarecer melhor o erro, pode alterar a frase de razão ou incluir um corpo para explicar o erro.

412 - A falha na pré-condição é usada para solicitações condicionais ao usar data da última modificação e ETags.

403 - Proibido é usado quando o servidor deseja impedir o acesso a um recurso.

A única outra opção possível é 422 - Entidade não processável.

Eu recomendaria 422. Não faz parte das principais especificações HTTP, mas é definido por um padrão público (WebDAV) e deve ser tratado pelos navegadores da mesma forma que qualquer outro código de status 4xx.

De RFC 4918 :

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) é inapropriado) e a sintaxe da entidade solicitada 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.

Se a solicitação não puder ser analisada corretamente (incluindo a entidade / organismo da solicitação), a resposta apropriada será 400 Solicitação incorreta [ 1 ].

A RFC 4918 declara que 422 Entidade Não Processável é aplicável quando a entidade solicitada é sintaticamente bem formada, mas semanticamente errônea. Portanto, se a entidade solicitada estiver ilegível (como um formato de email incorreto), use 400; mas se simplesmente não fizer sentido (como @example.com) use 422.

Se o problema é que, conforme indicado na pergunta, o nome de usuário / email já existe, você pode usar o 409 Conflict [ 2 ] com uma descrição do conflito e uma dica sobre como corrigi-lo (neste caso, "escolha um nome de usuário / email diferente "). No entanto, na especificação escrita, 403 Proibido [ 3 ] também pode ser usado neste caso, apesar dos argumentos sobre a Autorização HTTP.

412 Falha na pré-condição [ 4 ] é usado quando um cabeçalho de solicitação de pré-condição (por exemplo If-Match) fornecido pelo cliente é avaliado como falso. Ou seja, o cliente solicitou algo e forneceu pré-condições, sabendo muito bem que essas pré-condições podem falhar. 412 nunca deve ser lançado no cliente do nada e não deve estar relacionado à entidade solicitante propriamente dita .

É divertido retornar 418 I'm a teapotàs solicitações que são obviamente criadas ou mal-intencionadas e "não podem acontecer", como falha na verificação do CSRF ou falta de propriedades da solicitação.

2.3.2 418 Eu sou um bule de chá

Qualquer tentativa de preparar café com um bule de chá deve resultar no código de erro "418 sou um bule de chá". O órgão da entidade resultante pode ser curto e robusto.

Para mantê-lo razoavelmente sério, restrinja o uso de códigos de erro engraçados aos pontos de extremidade RESTful que não são diretamente expostos ao usuário.