RFC 9457 クイズ

**解説:** A: RFC 9457は新しいHTTP status code群を定義していない. またRFC 7807を現行仕様として残す文書でもない. B: RFC 9457はRFC 7807をobsoletesし, 基本data modelを継承しながらregistryや複数problemの扱いなどを明確化した. C: Problem Detailsは一般的なHTTP API形式である. 個別protocolが別のerror representationを規定している場合, 自動的には置き換えない.

**解説:** A: genericなapplication/jsonだけではProblem Detailsの処理規則を示さない. errorCodeもRFC 9457のstandard memberではない. B: application/problem+xmlはappendixで示されるXML形式であり, JSON encodingではない. C: application/problem+jsonがcanonical data modelのJSON serializationを示すregistered media typeである.

**解説:** A: RFC 9457はwrong JSON typeのstandard memberを無視するよう要求する. 他のvalidな情報は引き続き処理できる. B: JSON syntax自体はvalidでもmember typeだけが誤っている場合がある. response全体の拒否は要求されていない. C: 自動変換は実装ごとに異なる解釈を生む. 不正memberを無視することがinteroperableな処理である.

**解説:** A: relative type URIはbaseが変わると解釈を混乱させる. 通常consumerがtype URIをfailureごとに自動取得することも想定されていない. B: typeはproblem categoryのprimary identifierでabsolute URIが推奨される. locator URIは人向け文書を示せるがruntime取得は必須でない. C: typeを省略するとabout:blankとみなされる. occurrence固有のhuman-readableなdetailはstableなmachine identifierではない.

**解説:** A: status memberはadvisoryであり, intermediaryによる変更後は不一致になりうる. 2つ目のauthoritative status channelではない. B: RFC 9457は2つの数値から新しいstatusを作る規則を定義していない. 独自結合はinteroperabilityを損なう. C: generic HTTP softwareは実際のHTTP statusを使う. generatorはbody memberをresponseと一致させる必要があるが, transit後のrecipientは不一致を観測しうる.

**解説:** A: titleはproblem typeのshort summaryでありlocalization以外では変えない. detailはspecific occurrenceを説明しclientの修正を助けられる. B: titleを毎回変えるとtypeのstable summaryではなくなる. detailを固定するとoccurrence固有の状況を説明できない. C: どちらもhuman-readable fieldである. machine判断にはtypeとdocumented extension memberを使い, proseをparseしない.

**解説:** A: human-readable proseのparseはwordingやlocalizationの変更で壊れる. detailはmachine-readable extension channelではない. B: problem typeはstructured data用のextension memberを定義できる. unknown extensionをconsumerが無視する規則によりcompatibleに進化できる. C: standard memberの再定義は規定された役割を壊す. statusはHTTP status codeであり, titleはproblem typeのsummaryである.

**解説:** A: unrelated problemをgeneric containerへ入れるとHTTP statusとの対応が悪く, client behaviorも曖昧になる. universalな推奨ではない. B: 1つのHTTP responseが持つstatus lineは1つである. Problem Detailsは内部に複数の独立HTTP responseを作らない. C: 同じtypeの複数occurrenceはtype固有extensionで表現できる. typeが異なる場合は最もrelevantまたはurgentなproblemを返すことが推奨される.

**解説:** A: new problem type definitionはtype URI, short title, 利用するHTTP status codeを文書化する必要がある. B: generic failureにはplainなHTTP statusだけで足りる場合が多い. clientがproblem固有の処理を必要とするときにnew typeが有効になる. C: RFC 9457はHTTP Problem Types registryを設けた. semanticsが一致する登録済みtypeの再利用は不要なvocabulary分裂を避ける. D: type URIはcategoryを識別しdocumentationを提供できるが, implementation detailやoccurrence固有secretを公開する場所ではない.

**解説:** A: 一般HTTP RFCはapplication固有のwire representationを暗黙には変更しない. migrationには明示的なprotocol判断が必要である. B: stableなerror identifier, status整合, extensibility, disclosure制限は, 別のerror envelopeを使うbindingでも有効なreview criteriaになる. C: instanceはoccurrence identifierであり他memberをsanitizeしない. stack trace, token, internal path, log dataはsensitive informationを漏らしうる.