28

私は何度もそれをやった（そして多くの人がそうしているのを見た）が、それが適切かどうか疑問に思う：

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

これは、リクエストが適切な形式であったが、意味的に正しくない422 unprocessable entityことを意味することがわかりました。私が理解しているように、検証エラーはセマンティック エラーではない可能性があります。

注:私は一意性の検証について話しているので、この質問のように、これがユーザー エラーと見なされるかどうかはわかりません:検証の失敗に対して REST API サービスによって返される適切な HTTP ステータス コードは何ですか?

要約すると、ステータス 422 の使用を停止する必要がありますか? もしそうなら、代わりに何を使うべきですか？

4

4 に答える 4

36

注意: ポケのものの下に詳細な回答をしようとしましたが、それは不可能のようですので、ここで回答します。

検証エラーに 422 を使用しても問題ないと思います。

  1. Webdav RFC は、422 が「セマンティック エラー」を意味するとは言っておらず、サーバーが「含まれている命令を処理できなかった」と述べています ( https://www.rfc-editor.org/rfc/rfc4918#section-11.2を参照)。「セマンティック エラー」は、ユース ケースの例として引用したにすぎません。

  2. 500 は、「リクエストの実行を妨げた予期しない状況」のために予約されています ( https://www.rfc-editor.org/rfc/rfc2616#section-10.5.1 )。

500 は通常、実際のエラー (コード内でまったく処理されないクラッシュなど) 用に予約されています。検証エラーは処理され、「予期しない」ものではなく、クライアントは処理できるように (または処理できないように) 要求を変更する必要があります。その意味では、クライアントがエラーを起こしたことになります (たとえば、不正な形式の電子メール アドレスを送信すると、検証エラーがスローされますが、明らかにサーバー エラーではありませんよね?)。

私が見たほとんどの API は、このような場合に 400 または 422 を使用しています。おそらく、これに対する唯一の正解はありませんが、500 が当然の方法であると言うのは、私には間違っているように思えました。

お役に立てれば。

于 2013-08-17T01:38:29.283 に答える
17

vsほど単純ではないというjbbarthに同意します。422500

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

これは私が使用するパターンです：

if @record.invalid?
  # failure of validations => status 422
elsif @record.save
  # status 200
else
  # failure when saving => status 500
end
于 2014-02-06T02:13:17.527 に答える
2

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

それがクライアントのせいではなく、他の何か（クライアントが影響を与えることができない）がレコードの保存を妨げた場合、それはサーバーエラーであり、HTTP通信の意味での（クライアント）エラーではありません。

于 2013-03-06T17:21:18.450 に答える