要約

  • QUERYは要求contentとmedia typeで検索式を表し、safeかつidempotentなmethodとして登録された。その性質は実装者の義務であって、任意のhandlerに業務副作用がないという証明ではない。
  • cache keyにはcontentと関連metadataが必要である。retry、redirect、validator、Accept-Query、同等resourceのURIはclient、cache、originに異なる権限を配分する。

分析基盤へ、入れ子条件やprojectionを含む式を渡す場面を考える。GETは読取りに向くが、RFC 9110はGETで受け取るcontentに一般的な意味を定めていない。POSTならbodyを送れる一方、upload後に接続が切れたとき、methodだけを根拠に再実行の安全性を判断できない。

2026年6月にProposed Standardとして発行されたRFC 10008は、この間にQUERYを置いた。contentは必須で、media typeがquery表現の形式を示し、contentと関連metadataが対象resourceへの問いを構成する。IANAのregistryではQUERYがsafe=yes、idempotent=yes、Accept-Queryがpermanent fieldとして登録されている。

これはbody付きGETではなく、POSTの言い換えでもない。safeとは、要求された意味が業務stateの変更ではないこと。idempotentとは、同一要求を複数回行った意図上の効果が一回と同じことであり、応答byteの同一性ではない。課金、枠の確保、one-time tokenの消費、承認、credential rotationを行う処理は、重複を抑止していてもsafeなqueryではない。

method propertyは他者に依存を許す宣言

clientはsafe methodを自動化しやすい。transport libraryは、初回が実行されたか不明な障害後にidempotent methodをretryできる。cacheは理解するmethodにだけ保存規則を適用する。originがQUERYを公開することは、他の参加者にその性質を前提としてよいと伝える行為である。

routeのannotationだけでは足りない。method、contentとmedia typeのfingerprint、identity context、application実行、観測されたeffect、返したrepresentationを一つのtraceで結ぶ。retry時には、初回がbusiness logicへ到達したか、二回目が禁止された変化を生んだかを答えなければならない。

付随的なloggingは読取りと共存し得る。しかしquotaの減算、queue cursorの前進、権利の消費、外部命令の発行は要求の結果である。内部関数名ではなく、利用者と第三者に生じる効果で判定する。

bodyはcache identityの外にない

RFC 10008は、QUERY responseのcache keyへ要求contentと関連metadataを含めるよう求める。同じmethodとURIでも、bodyが違えば別の問いである。URIだけのkeyは、あるfilterの結果を別のfilterへ返し得る。

keyを作る前にcacheがcontent全体を読む必要も生じる。streaming中心だった経路にbuffer、memory、latency、backpressureの問題が入る。maximum body sizeとtimeoutは実装細部ではなく、導入条件である。

media typeを理解するcacheは、意味に影響しない差をnormalizeできる。ただし、その権限は危険でもある。無視可能と定義された空白を整えることと、順序に意味があるarrayを並べ替えることは違う。誤ったpositive matchはoriginへ届く前に別の答えを返す。no-transformはHTTP上の指示であり、key materialがどの層でもcanonicalizeされなかったという監査証拠ではない。

試験は二方向で行う。同じ意味の異なるencodingと、似て見えるが異なる意味の組である。duplicate field、数値、Unicode、default、content encoding、signature input、authorization partitionを含める。全parserが共有する規則がないなら、差を残す方が可逆的だ。

結果への命名は寿命を変える

同等resourceはtarget resource、QUERY content、関連metadataから導かれる。originはURIを割り当て、後のGETで取得させられる。一時的な式が、共有・保存可能な名前を持つ瞬間である。

LocationとContent-Locationは同じcanonical URLではない。成功したQUERYで、LocationはGETできる同等resourceまたはquery resourceを指し得る。Content-Locationは返されたrepresentationに対応するURIをHTTP semanticsに従って示す。両者を統合すると、originが何を名付けたかという宣言を失う。

名前は情報を再露出させる。account idや秘密filterを生成URIに入れれば、history、access log、reference、共有画面へ戻る。opaque identifierは露出を減らすが、有効期限、access control、revocationの責任を生む。最初の実行を許した権限contextよりURIの方が長生きする場合もある。

RFC 3986はidentifierの構文を定めるが、公開範囲や寿命は決めない。名付けるoriginが、その永続性と漏えい結果を引き受ける。

redirectはmethodの統治である

301、302、307、308ではQUERYを維持する。POSTに対する歴史的なGET変換の例外は適用されない。303だけがGETへの移行を明示する。前者はcontentを新しいtargetへ再送し、後者はresourceを参照する。

gatewayが慣習でQUERYをGETへ変えればbodyが失われるかURIへ再挿入される。POSTへ変えればretryの根拠が消える。各status、cross-origin、credentialの扱い、size limitを別々に検証する必要がある。

conditional QUERYのvalidatorは、同等resourceへGETしたとき選ばれるrepresentationを基準にする。content negotiationとauthorizationは残る。query bodyのhashだけでresponse representationを識別したことにはならない。

Accept-Queryはfreshで局所的な証拠

Accept-QueryはRFC 9651のListで受理するmedia typeを広告する。同じpathでURIのquery componentを無視した範囲に適用され、複数あれば最も新しいfreshな値が使われる。

これは任意の式の妥当性や全nodeの一致を保証しない。fieldを出したresponse、freshness、path、deployment versionを記録する。rolling deploymentでは能力広告自体が分岐する。

browserには別の壁もある。Fetch StandardのCORS-safelisted methodはGET、HEAD、POSTで、QUERYは含まれない。cross-origin利用にはpreflightが必要であり、applicationの対応だけではgatewayやsecurity policyを通過できない。

URIにないことは、誰にも見えないことではない

QUERYは式をURI専用logやcopyされたlinkから遠ざけられる。しかしcontentはclient、browser tool、TLS termination、gateway、cache、trace、originを通る。retryで再送され、redirectで別の受領者へ移り、生成URIで再び公開され得る。

Lu Hengのデータ主権における形式と実務の区別が有効である。originは形式上semanticsを決めるが、実際のcustodyはcontentやfingerprintを受け取る全層へ分散する。

最小初期仕様、局所的な将来決定、自発的採用という考え方では、共通層はmethod、property、cache義務、redirect、能力広告に限る。query languageと命名はorigin、送信とretryはclient、正しいidentityを守れる範囲のreuseはcacheに残る。

running code優先は証拠の位置を決める。RFCは期待を証明する。handlerの安全性、retryの冪等性、keyの完全性、URIの非露出はexecution traceだけが証明できる。