[1] 422
(Unprocessable Entity)
は、要求の payload body に含まれているデータが構文的には正しいものの、
内容が仕様的に正しくなく処理できないことを表す状態符号です。
[4] 422
は、鯖が要求の payload body の
MIME型は理解でき、構文的には正しかったものの、
記述されている指示に従って処理することはできなかったことを表す状態符号です >>3。
[23]
このように 4xx
エラーの意味はかなり細分されていて、
一見便利そうですが、
実応用に当てはめて考えてみるとその使い分けは必ずしも明確とはいえません。
一方で、
エラーの細分化は要求の送信者に十分な情報を与えることが主たる目的ですが
(他にはサーバーのアクセスログからエラーの分析を行うための便宜というのもあるでしょう)、
そのために十分なほどに細分化されているとはいえません。
つまり帯に短し𧜎に長しというべき状況なのであります。
[24]
応用は、
状態符号の選択に迷うのであれば、
400
を使えばよろしいでしょう。
適用可能性に自信がないところで敢えて 422
を使う必要性はありません。
エラーの詳細は、
応答に
JSON
形式で含めるなり、
HTTPヘッダーに適宜記述するなり、
クライアントが扱いやすい方法を採ればよい。
[13] PATCH
要求の payload body を理解できるものの、
処理はできない場合には、 422
応答を返すべきです >>12。
[9] 要求で JSON を求める Web API で、入力が期待される構造でなかった時に
422
応答が返されることがよくあります。
[15] Linked Data Patch Format ( 版) https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html#h-error-handling
[21] RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH () https://tools.ietf.org/html/rfc5323#section-5.11
[22]
GitHub
の
API
は要求に含まれる公開鍵が未対応の形式 (秘密鍵形式の場合を含みます。)
のとき、
422
を返すようです。
[8] S-HTTP は別の意味 (SHTTP Proxy Authentication Required) で使っていました >>423。
415
がより適当です >>3。