ToppyMicroServices

RFC 9457 クイズ

HTTP APIのProblem Details

ENJA
0 / 0

参照仕様

Q1: RFC 9457はRFC 7807とどのような関係にある?

単一選択
**解説:** 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を規定している場合, 自動的には置き換えない.

Q2: Problem Details objectのJSON形式を運ぶresponse media typeはどれ?

単一選択
**解説:** 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である.

Q3: standard memberの値が規定と異なるJSON typeだった. conforming consumerはそのmemberをどう扱う?

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

Q4: type memberの設計としてRFC 9457に最も合うものはどれ?

単一選択
**解説:** 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ではない.

Q5: gatewayがoriginのHTTP 404をHTTP 502へ変更したが, bodyのstatus: 404は残った. generic clientはどちらを使う?

単一選択
**解説:** 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は不一致を観測しうる.

Q6: 同じproblem typeの複数occurrenceで, titleとdetailをどう使い分ける?

単一選択
**解説:** 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しない.

Q7: quota problemでlimitとreset timeをclientへ伝えたい. 最も適切な表現はどれ?

単一選択
**解説:** 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である.

Q8: 1つのoperationで複数failureを検出した. RFC 9457のguidanceに合うresponse方針はどれ?

単一選択
**解説:** 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を返すことが推奨される.

Q9: 安定したクライアント向け契約を保ち、内部情報を漏らさない再設計はどれ？

単一選択

APIはtype: about:blank、HTTP 400、detail: "account locked in AuthService.java:418"を返す。clientは英語のdetail textをmatchしてretryするか停止する。serverはlock reasonとunlock timeも伝えたい。

**解説:** RFC 9457 Sections 3.1.1と3.1.4はtypeを主要なmachine identifierとし、detailのparseを避けるよう求める。Section 3.2は型付きextension memberを提供し、Sections 4と5はAPI problem semanticsをdebugging dataから分け、implementation internalの露出を警告する。Cならreasonとunlock timeを安定したfieldにできる。他の選択肢はhuman向けまたはoccurrence固有dataをprotocol contractにし、disclosure riskも残す。

Q10: 相互運用性を保ち、情報漏えいを抑える設計レビュー上の提案はどれ？

単一選択

A2A bindingはgoogle.rpc.Status系error bodyを規定する。browser-facing gatewayがそれをapplication/problem+jsonへ変換し、agentはdetailをparseしてretryを判断し、central loggerは変換後object全体を保存する。instance URIのqueryにはbearer tokenがあり、detailにはinternal pathがある。

**解説:** RFC 9457は他protocolが選んだerror envelopeを上書きしない。adapterで使うなら明示的mappingが必要である。Sections 3.1.1、3.1.4、3.2はdetailのparseではなく、安定したtype・extension semanticsを使えるようにする。Section 5は生成情報の慎重なreviewを求め、Problem Details自体がsecretやimplementation dataをsanitizeするわけではない。Cはwire、decision、response、loggingの各boundaryを扱う。generic HTTP softwareにとってHTTP statusは引き続きauthoritativeである。