[1] [DFN[[CODE(HTTP)[[[422]]]]]] ([DFN[[[Unprocessable Entity]]]]) は、[[要求]]の [[payload body]] に含まれているデータが構文的には正しいものの、 内容が仕様的に正しくなく処理できないことを表す[[状態符号]]です。 * 仕様書 [REFS[ - [3] '''[CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) ''' - [12] [CITE@en[RFC 5789 - PATCH Method for HTTP]] ([TIME[2014-09-22 15:11:26 +09:00]] 版) ]REFS] * 意味 [4] [CODE(HTTP)[[[422]]]] は、[[鯖]]が[[要求]]の [[payload body]] の [[MIME型]]は理解でき、構文的には正しかったものの、 記述されている指示に従って処理することはできなかったことを表す[[状態符号]]です [SRC[>>3]]。 ;; [2] [[MIME型]]に対応していない時は、 [CODE(HTTP)[[[415]]]] がより適当です [SRC[>>3]]。 ;; [5] [[payload body]] が構文的に正しくない時は、 [CODE(HTTP)[[[400]]]] がより適当です [SRC[>>3]]。 ;; [11] [[整形式]]であっても[[要素]]の構造が仕様上正しくない時には [CODE(HTTP)[[[400]]]] を返すともされており、 [CODE(HTTP)[[[422]]]] との使い分けはよくわかりません。 ([[[CODE(HTTP)@en[PROPFIND]]]>>44]参照。) ;; [10] [[外部実体参照]]が含まれ、[[鯖]]がこれを拒絶したい時は、 [CODE(HTTP)[[[403]]]] を使うことになっています。 [23] このように [CODE[4xx]] エラーの意味はかなり細分されていて、 一見便利そうですが、 実[[応用]]に当てはめて考えてみるとその使い分けは必ずしも明確とはいえません。 一方で、 エラーの細分化は[[要求]]の送信者に十分な情報を与えることが主たる目的ですが (他にはサーバーのアクセスログからエラーの分析を行うための便宜というのもあるでしょう)、 そのために十分なほどに細分化されているとはいえません。 つまり[[帯に短し𧜎に長し]]というべき状況なのであります。 [24] [[応用]]は、 [[状態符号]]の選択に迷うのであれば、 [CODE[400]] を使えばよろしいでしょう。 適用可能性に自信がないところで敢えて [CODE[422]] を使う必要性はありません。 エラーの詳細は、 [[応答]]に [[JSON]] 形式で含めるなり、 [[HTTPヘッダー]]に適宜記述するなり、 [[クライアント]]が扱いやすい方法を採ればよい。 ;; [26] 例えば [[Web API]] の [[validation]] エラーでは [CODE[400]] を使うのがいいでしょう。 * 文脈 [13] [CODE(HTTP)@en[[[PATCH]]]] [[要求]]の [[payload body]] を理解できるものの、 処理はできない場合には、 [CODE(HTTP)[[[422]]]] [[応答]]を返す[['''べきです''']] [SRC[>>12]]。 [EG[ [14] 例えば[[パッチ文書]]を適用した結果 [[XML文書]]が[[整形式]]でなくなるなら、 [CODE(HTTP)[[[422]]]] [[応答]]を返すことができます [SRC[>>12]]。 ]EG] [9] [[要求]]で [[JSON]] を求める [[Web API]] で、入力が期待される構造でなかった時に [CODE(HTTP)[[[422]]]] [[応答]]が返されることがよくあります。 * 実装 [15] [CITE@en[Linked Data Patch Format]] ([TIME[2015-03-04 15:20:56 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [16] [CITE@en[RFC 7482 - Registration Data Access Protocol (RDAP) Query Format]] ([TIME[2015-03-26 08:10:36 +09:00]] 版) ]FIGCAPTION] > If a server receives a search request but cannot process the request > because it does not support a particular style of partial match > searching, it SHOULD return an HTTP 422 (Unprocessable Entity) > '''['''RFC4918''']''' response. When returning a 422 error, the server MAY also > return an error response body as specified in Section 6 of '''['''RFC7483''']''' > if the requested media type is one that is specified in '''['''RFC7480''']'''. ]FIG] [FIG(quote)[ [FIGCAPTION[ [6] [CITE@en[Uber API Reference Guide]] ([TIME[2015-09-25 03:53:01 +09:00]] 版) ]FIGCAPTION] > 422 Invalid request. The request body is parse-able however with invalid content or there are issues with a rider's user account. ]FIG] [FIG(quote)[ [FIGCAPTION[ [17] [CITE[Asterisk Project : Asterisk 12 Applications REST API]] ([TIME[2014-10-09 21:00:13 +09:00]]) ]FIGCAPTION] > 422 - Event source does not exist. ]FIG] [FIG(quote)[ [FIGCAPTION[ [18] [CITE[Asterisk Project : Asterisk 12 Bridges REST API]] ([TIME[2014-10-09 21:00:17 +09:00]]) ]FIGCAPTION] > 422 - Channel not in Stasis application ]FIG] [FIG(quote)[ [FIGCAPTION[ [19] [CITE@en[API reference overview | Postmark Developer Documentation]] ( ([[Wildbit, LLC]]著, [TIME[2017-01-19 01:49:47 +09:00]])) ]FIGCAPTION] > 422 — Unprocessable Entity > Something with the message isn’t quite right, this could be malformed JSON or incorrect fields. In this case, the response body contains JSON {ErrorCode: 405, Message: "details"} with an API error code and message containing details on what went wrong. ]FIG] [FIG(quote)[ [FIGCAPTION[ [20] [CITE@en[Mapbox API Documentation]] ([TIME[2017-05-10 01:21:59 +09:00]]) ]FIGCAPTION] > InvalidInput 422 The given request was not valid. The message key of the response will hold an explanation of the invalid input. ]FIG] [21] [CITE@en[RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH]] ([TIME[2017-10-01 13:49:21 +09:00]]) [22] [[GitHub]] の [[API]] は[[要求]]に含まれる[[公開鍵]]が未対応の形式 ([[秘密鍵]]形式の場合を含みます。) のとき、 [CODE[422]] を返すようです。 [FIG(quote)[ [FIGCAPTION[ [25] [CITE@en[Issues - GitHub Docs]] ([TIME[2022-04-30T01:24:53.000Z]]) ]FIGCAPTION] > 422 > Validation failed ]FIG] * 歴史 [FIG(quote)[ [FIGCAPTION[ [7] RFC 2518 (WebDAV) 10.3 422 Unprocessable Entity ]FIGCAPTION] > The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. [CODE(HTTP)[422]] (処理不能実体) 状態符号は、 サーバーが要求実体の内容型は理解した (従って [CODE(HTTP)[[[415]]]] (未対応の媒体型) 状態符号は不適切である) し、要求実体は正しい (従って [CODE(HTTP)[[[400]]]] (悪い要求) 状態符号は不適切である) ものの含まれている指示を処理することができなかったことを意味します。 例えば、 XML 要求本体が整形式である (つまり構文的には正しい) が意味的に誤っている XML 指示のときにこの誤り状況が発生するかもしれません。 ]FIG] ** S-HTTP 422 [8] [[S-HTTP]] は別の意味 ([DFN[[[SHTTP Proxy Authentication Required]]]]) で使っていました [SRC[>>423]]。 [REFS[ - [423] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ( ([TIME[2013-07-20 22:21:48 +09:00]] 版)) ]REFS] * メモ