HTTPステータス422は、一意性検証に失敗したレコードに適していますか？

Question

私は多くの時間それを行って（そして多くの人がそう見える）が、私はそれが適切であるかどうか疑問を開始しました：

if @record.save 
    # status 200 
else 
    # failure of validations => status 422 
end 

は、今私は422 unprocessable entityがrequest was well-formed, but not semantically correctを意味していることがわかります。私が理解しているように、検証エラーは意味上のエラーではないかもしれません。

注：私は約一意性の検証を話しているので、私は、これは、この質問のように、ユーザー・エラーとしての資格わからない：What's an appropriate HTTP status code to return by a REST API service for a validation failure?

をまとめると：私は使用を中止すべきですステータス422？もしそうなら、私は代わりに何を使うべきですか？

Answer 1

NB：ポケの下で詳細な回答を試みましたが、可能ではないようですので、ここで回答します。

私は422を使用して検証エラーがうまくいくと思います。 422を言っていない

1. のWebDAV RFCは、サーバーが（http://tools.ietf.org/html/rfc4918#section-11.2を参照してください）「に含まれる命令を処理することができませんでし」だったと言い、「セマンティック・エラー」を意味します。 「セマンティックエラー」は、ユースケースの例として引用されています。

2. 500は、「要求を満たすことができなかった予期しない条件」（http://tools.ietf.org/html/rfc2616#section-10.5.1）のために予約されています。

500は通常、実際のエラーのために予約されています。クラッシュのような、あなたのコード内で全く扱われないもの。検証エラーは処理され、「予期しない」ものではなく、クライアントは処理できるように要求を変更する必要があります。その意味で、クライアントはエラーを出しました（例えば、不正な電子メールアドレスを送信すると、検証エラーが発生しますが、明らかにではなく、サーバーエラーです）。

ほとんどのAPI私はこのような場合に400または422を使用しています。たぶん、これに対する真の答えは1つではありませんが、明らかに500が明らかに私には間違っていると言っています。

これが役に立ちます。

Answer 2

私の理解では、HTTP要求は正しかったが何らかの理由でサーバー側で失敗した場合、サーバーの問題があったことを示す5xxエラーがスローされます。あなたがそれをさらに指定することができない限り、単純な500で十分です。

クライアントの障害ではなく、（クライアントが影響を与えない）何かがレコードの保存を妨げた場合、HTTP通信の意味での（クライアント）エラーではなくサーバーエラーです。 。

Answer 3

jbbarth私は422と500のように単純ではないことに同意します。

422は検証エラーには適していますが、dbエラーもキャッチしたくありません。

if @record.invalid? 
    # failure of validations => status 422 
elsif @record.save 
    # status 200 
else 
    # failure when saving => status 500 
end 

Answer 4

422を返すことは細かいですが、私は409競合を返す必要があります一意性の検証に失敗したと言うだろう：

この

は、私が使用するパターンです。