web-dev-qa-db-ja.com

クライアントエラーリクエストの400対422

クライアント要求エラーに対して返す適切なhttpステータスコードに関する多くの投稿と記事を読みました。 RFC 7231 で再定義されているため、400を使用することをお勧めする人もいます。

400（Bad Request）ステータスコードは、クライアントエラーであると認識される何か（不正な形式の要求構文、無効な要求など）が原因で、サーバーが要求を処理できない、または処理しないことを示します。
メッセージフレーミング、または不正なリクエストルーティング）。

私はこの声明をrfc 7231の付録Bで見つけました。

400（Bad Request）ステータスコードが緩和され、
構文エラーに制限されています。 （セクション6.5.1）

これは、あらゆるタイプのクライアントエラーを悪い要求と見なすことができるということですか？クライアント要求には400を使用し、メッセージでより具体的なエラーを指定する方がよいでしょうか？


一方、他の人は422（Unprocessable Entity）を使用する方が良いと言っています。これはセマンティクスに重点を置いていますが、http-1.1のwebDAV拡張である RFC 4918 にのみリストされています。

422（Unprocessable Entity）ステータスコードはサーバーを意味します
リクエストエンティティのコンテンツタイプを理解する（したがって、
415（サポートされていないメディアタイプ）ステータスコードは不適切です）、および
リクエストエンティティの構文が正しい（したがって、400（不正なリクエスト）
ステータスコードは不適切ですが、含まれている指示を処理できませんでした。たとえば、このエラー状態は、XML
リクエストの本文には整形式（つまり、構文的に正しい）が含まれていますが、
意味的に誤りのあるXML命令。

このwebDAV拡張コードを使用してhttpリクエストを処理できますか？ 422の場合、コアhttpコードに含まれていなくても使用できますか？.

クライアントエラーには400または422を使用する必要がありますか？

ここに私が考えているクライアントエラーの可能性があります：

1.) Invalid parameter. The client provided parameters but are found invalid. Example: I said that the userId is 1, but when I checked there's no userId of 1. Another example of invalid parameter is wrong data type.
2.) Missing required parameters
3.) Let's say I need to hash a value based on given params and it failed 
4.) Blocked content is being used. Like, i want to apply for membership and i passed the userId of 1. However, userId of one is blocked / deactivated
5.) When I try to delete an entry but the entry is still being used in another table. 
6.) Let's say i require a signature in my payload and the signature does not match when recalculated in the backend
7.) Let's say I have a value that counts a specific attribute like "shares" and it has reached the maximum value like 10.
etc...


有益な情報があれば高く評価されます。みんなありがとう！

更新：私はgoogle apiエラーをチェックしましたが、422は使用していません。一方、Twitterは422を使用しています。これまでにないほど混乱しています>。 RFC docと422ではありません。でも私は間違っているかもしれません。

error-handlinghttp-status-codeshttp-errorhttp-status-code-400http-status-code-422
7
cessmestreet

このWebDAV拡張コードを使用してHTTPリクエストを処理できますか？ 422の場合、コアHTTPコードに含まれていなくても使用できますか？.

HTTPは拡張可能なプロトコルであり、 422 は IANAに登録済み であり、標準のステータスコードになります。したがって、アプリケーションで 422 の使用を妨げるものは何もありません。

クライアントエラーには400または422を使用する必要がありますか？

状況によって異なりますが、両方を使用できます。一般的に、 400 を使用して、ペイロードのsyntaxエラーまたはURLの無効なパラメーターを示します。そして、ペイロード内のセマンティック問題を示すために 422 を使用します。

例として、 GitHub v3 API で使用される approach を参照してください。

クライアントエラー

リクエストの本文を受信するAPI呼び出しのクライアントエラーには、次の3つのタイプがあります。

  1. 無効なJSONを送信すると、400 Bad Request応答が発生します。

    HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

  2. 間違ったタイプのJSON値を送信すると、400 Bad Request応答が発生します。

    HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

  3. 無効なフィールドを送信すると、422 Unprocessable Entityレスポンスが返されます。

    HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

最も適切な4xxステータスコードの選択

Michael Kropat まとめて 一連の意思決定表 これは、各状況に最適なステータスコードを決定するのに役立ちます。 4xxステータスコードについては、以下をご覧ください。

HTTP 4xx status codes

HTTP APIの問題の詳細

HTTPステータスコードは、役立つエラーに関する十分な情報を伝えるのに十分でない場合があります。 RFC 7807 は、HTTP APIの問題についてクライアントに通知する単純なJSONおよびXMLドキュメント形式を定義します。これは、APIのエラーを報告するための優れた出発点です。

また、application/problem+jsonおよびapplication/problem+xmlメディアタイプも定義します。

18
cassiomolin